For some reason, it looks like git cherry-pick pulls in other commits when flies have merge conflicts. These go away when we use git mergetool but prevent us from manually editing the merge-conflicted file.
Does anyone know why this happens?
To show what I mean, let’s take a fresh new git 1.7.4 repository with a single file foo:
header
footer
Let’s create a new branch at this point called bar. Back in the master, let’s add three changes to this file in separate commits.
Commit 1:
header
+add something
+
footer
Commit 2:
header
add something
+add something else
+
footer
Commit 3:
header
add something
add something else
+important change!
+
footer
Since this last commit is important, after the fact we decide we want to pull this back to branch bar and git cherry-pick <commit> on that branch.
Unfortunately, this produces an interesting merge conflict in file foo:
header
<<<<<<< HEAD
=======
add something here
add something else here
important change!
>>>>>>> 356ca3c... important change
footer
Note that git mergetool seems to do the right thing and produces this:
header
+important change!
+
footer
Why does the merge-conflicted file contain commits previous to the one we tried to cherry pick?
Git is sceptical and will not do a merge if it does not find the proper edges to what the patch would apply to. The patch would apply to a line number that does not exist. Inspect the patch fro that commit and see that it is applied at a line number that does not make sense. Since it is a cherry-pick, it does not take into consideration how the file got to be that way and that it would be ok to add that entry. Hope that makes sense.