git cherry-pick merge conflict pulling in other commits?

Question

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?

Answer 1

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.