I ran into a situation where git cherry-pick X
would have some conflicts, but also created extra inserts (when verified with git diff
).
I then
When you cherry-pick a commit, it commits the result using all the metadata of the commit, not just the diff it represents - you'll get the original commit message and author. Your patch pipeline will get you the working tree contents that you want, but then you'll have to commit it yourself, hopefully with git commit -c <original-commit>
to copy the metadata like cherry-pick would have. Cherry-pick also has some additional options that could be helpful, and can accept multiple commits (perhaps specified as a rev-list range). patch
obviously doesn't support any of that.
I'm not sure about your assertion that the result was "cleaner". Are you suggesting that git applied the diff differently than patch
did?
This might help:
http://technosophos.com/2009/12/04/git-cherry-picking-move-small-code-patches-across-branches.html
It might be partly off topic, but as you can see, cherry picking seems to track code blocks across the code in some way, much more advanced than what I would guess patch does, which is probably just parsing the two codebases sequentially and side by side, and mark lines that differ.