git add .; git commit -am 'master add line a'
git checkout -b dev
git commit -am 'dev add line b'
git commit -am 'dev add line c'
git checkout master
git cherry-pick dev
error: could not apply 08e8d3e... dev add line c
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
diff --cc a
@@@ -1,1 -1,3 +1,6 @@@
++>>>>>>> 11fff29... abc
Try again your cherry-pick after:
git config merge.conflictstyle diff3
You will get a more detailed diff:
<<<<<<< HEAD ||||||| parent of 5b2a14c... dev add line c b ======= b c >>>>>>> 5b2a14c... dev add line c
It shows that, when applying the patch represented by
dev's HEAD (
c), Git does not know of a common ancestor; it defers to:
c'after a line '
bat all on top of which it could apply the added change '
Cherry-picking takes a commit and applies the change that it introduces.
Here the change introduced is: add
c on top of
And the destination commit has no
b at all, so for Git:
b" (or never had it in the first place, which is the case here, but Git does not know that),
bon top of which
As far as Git knows when trying to apply that patch (and that is all
git cherry-pick does: apply patch. It does not look for the history of the cherry-picked commit at all), that is a conflict: concurrent modification.
If you are sure of the way that resolution should go, you can do:
> git cherry-pick -Xtheirs dev [master 7849e0c] dev add line c Date: Wed Aug 17 08:25:48 2016 +0200 1 file changed, 2 insertions(+)
Then, you would see
c added to the original commit, without any conflict (since you indicated how to resolve it with the option '
-Xtheirs' passed to the default merge strategy