3

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?

Alan Krueger
  • 4,701
  • 4
  • 35
  • 48

1 Answers1

0

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.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • Do you have supporting references for this? My question appears to be similar to http://stackoverflow.com/q/7802252/7708 There, you said that cherry-pick "effectively makes a patch" for a single commit; this is consistent with what I've been previously told about cherry-pick. Your answer above suggests it's more complicated than that. – Alan Krueger Feb 23 '12 at 16:34
  • It's not more complicated. Git looks at where the patch will be applied and if the edges don't match up, it's considered a conflict. If you merge, then git considers how the file got to the state they are in now by considering the history. – Adam Dymitruk Feb 24 '12 at 01:17