5

I have a git tree that looks like the following:

enter image description here

Because of the review tool we use, we cherry pick changes in rather than merging them. This leaves us with some logical duplicates, whose branch I then just delete. For example, the change one below ssl_tests "Modification: Changing name..." can also be seen in dev.

Now, perhaps this is a lack of understanding on my part of cherry pick, but those commits have different hashes and so are different commits right? Even though they are logically the same.

However, when I go to rebase ssl_tests onto dev, git manages to figure out that those cherry picked commits are upstream and then only rebases the "New Feature: Unit tests..." commit from ssl_tests.

As per usual, with git, this is great! This is exactly what I want! My question though, is how does git figure out that it doesn't need to rebase the other commits if they have different hashes?

Thanks! Stephen

steprobe
  • 1,659
  • 3
  • 17
  • 32
  • A good post about merging magic in Git is [How and/or why is merging in Git better than in SVN?](http://stackoverflow.com/q/2471606/11343) – CharlesB Nov 24 '11 at 10:14

1 Answers1

5

Git is looking at more than just the SHA1 here. It's actually considering the contents of the commit. It sees that the trees resulting from applying the commit and not applying the commit are the same; that is, the commit would be empty if applied to the new base. Thus, rebase is smart enough to know that it needn't bother including those commits.

Nick Lewis
  • 4,150
  • 1
  • 21
  • 22