5

I have squashed 2 commits (A and B) into one new commit (C). The previous two commits (A and B) where removed. I pushed these commits from my development repo to a central(bare) repository. The git-log on both repos confirms that commits A and B have been removed. The problem is when I do a pull on a third repository which already had (A and B) it now has all three commits (A, B and C).

I would have thought the pull would synchronise these changes. Do I need to checkout A~1 and then merge in the new changes? This seems like a hassle, especially in a production environment.

Josh Lee
  • 171,072
  • 38
  • 269
  • 275
Benbob
  • 13,876
  • 18
  • 79
  • 114
  • 2
    It is generally recommended that git-rebase only be used on code that hasn't been shared with other repositories for precisely this reason. I can't concisely explain why, but it will make sense if you read "Git from the Bottom Up" – Amanda Mitchell Jan 07 '11 at 01:55
  • [How do I recover/resynchronise after someone pushes a rebase or a reset to a published branch?](http://stackoverflow.com/questions/4084868/how-do-i-recover-resynchronise-after-someone-pushes-a-rebase-or-a-reset-to-a-publ) – Josh Lee Jan 07 '11 at 07:07

1 Answers1

10

This is mostly covered in "Recovering from upstream rebase", but it’s a bit obfuscated for my tastes.

You should know that git pull origin master is exactly equal to git fetch master; git merge origin/master. In other words, you have asked git to merge B and C together. There is a reason why it is inadvisable to rebase changes which have already been published: because it is quite easy to resurrect the old commits.

Since this was a simple squash, git pull --rebase will be able to figure this out. Reset to where you were before the erroneous merge, and say git pull --rebase origin master (or git rebase origin/master, since you’ve already fetched). This will magically transplant A, B, and any later commits onto C, and it will notice that A + B = C.

You may wish to make this the default, as it lets you avoid messes like this — set configuration branch.<name>.rebase to true.

Josh Lee
  • 171,072
  • 38
  • 269
  • 275
  • Worked great thanks. `First, rewinding head to replay your work on top of it...` The config tip is also very good. I'm always being impressed by how powerful git is. – Benbob Jan 07 '11 at 03:52