3

So from my understanding cherry-picking a commit from one branch to another creates a completely new hash signature although the actual code changes are the same. I believe this is because the commit hash signature depends upon the branch name and commit time among other things.

Because of this I have been led to believe that if a bug fix has been made in a feature branch and another developer needs this fix, the correct solution is to cherry pick this fix into its own branch, and merge that branch into the common branch both the feature branches branched from. Then the original bufix commit in the feature branch should be deleted and finally both feature branches simply re-base on-top of the common branch which now contains the bugfix.

However, it seems this is not how others interpret using cherry-pick. I thought that if a commit is cherry-picked from one feature branch into another and both are merged back into common, then these separate commits cause one of three things to happen;

  • 'duplicate' commits in the history which introduce the same code changes
  • a merge conflict that has to be handled manually
  • introduction of duplicated lines of code.

Have I interpreted cherry pick incorrectly?

myol
  • 8,857
  • 19
  • 82
  • 143
  • In my case, two identical commits on different branches (one cherry picked) shouldn't cause a merge conflict or duplicated lines of code. Why are you sure of that? – lubilis Sep 02 '16 at 09:51
  • @lubilis I am not sure of it to be honest. I just experience it often enough to wonder if it is how we are using cherry-pick or something else. – myol Sep 02 '16 at 10:48

1 Answers1

3

No, if you cherry-pick a commit from one branch into another, it will get a different hash, yes. Not because of the branch name, a branch is just a post-it that is stuck to a commit. But the whole history of a commit is part of the hash calculation so two commits that introduce the same changes but on top of a different history are essentially two different commits that introduce the same changes.

If you rebase one branch onto another and both have commits that introduce the same changes (cherry-picked from one to the other) the rebased branch will not contain both commits, but the commit that is rebased onto the history where the change is already introduced will be left out like it was never done.

If you merge the branches, there will be no conflict due to the cherry-picking because both branches did the same changes and Git sees and correctly handles this. If you do other changes on the same files, those changes might produce conflicts that need to be resolved.

Vampire
  • 35,631
  • 4
  • 76
  • 102
  • Thank you for the clarification and explanation. So just to confirm, when merging both branches back into the common branch (rather than rebasing one onto the other) the second merged branch will have the cherry-picked commit skipped? – myol Sep 02 '16 at 09:55
  • No, if you merge, the commit is not skipped, as a merge works not commit-wise. A rebase works commit-wise as it takes the commits you rebase and applies them one-by-one onto the new base commit, leaving out commits that do not introduce changes which is the case for cherry-picked commits. A merge compares what was changed and applies that at once. But as the introduced changes are the same, there will not be a conflict, because doing the same thing twice is not a conflict, or rather is automatically resolved. – Vampire Sep 02 '16 at 10:00
  • Ok I see, the conflict is automatically resolved but both commits then appear the common branch history? – myol Sep 02 '16 at 10:12
  • On a merge this should be the case, yes – Vampire Sep 02 '16 at 14:33