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.
