The problem I see with your interpretation of what went wrong (which I simply assume to know), is that you attribute the resulting conflict markers to git-cherry-pick not working as expected.

I suspect that git-cherry-pick just doesn't know where to put the patch and defaults to git-merge looking for common ancestors in order to find out - which he does. However, git-merge is still not able to merge without a conflict. I don't think any of git's merge strategies will do what you hope for in this example (because I tried them), but there are ways to favor different behavior (merge strategies), for example favor the other guy (the commit you're picking), such as the following example shows:


git cherry-pick b931360 --strategy=recursive -Xtheirs

Please note that while I did test your example, I am not a git developer (so I have not seen the actual implementation) and I might be wrong about what actually happened. A second - more educated - opinion on this would be great

--
You received this message because you are subscribed to the Google Groups "Git for 
human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to