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 re-ran git show X > my.patch
, and then did patch -p1 < my.patch
on my tree.
I got better results, some conflicts, but a much cleaner result.
What does git does special with cherry-picks? I use git 1.7.0.4.
Edited:
By cleaner results, I mean the resulting tree matched a lot more the results of git show X
, whereas the git cherry-pick
included a lot more code.
Besides being used for different tasks, the most significant difference is that git-cherry-pick changes the history of a branch, while git checkout is being used only to jump to a specific point in time (a specific commit) in the branch's history, without changing it.
git cherry-pick is like "Convert the specified commit into a patch and apply this patch here". git revert is like "Convert the specified commit into a patch, 'invert' this patch (like in patch -R ) and apply it here". Both commands can lead to conflicts.
git cherry-pick is a powerful command that enables arbitrary Git commits to be picked by reference and appended to the current working HEAD. Cherry picking is the act of picking a commit from a branch and applying it to another. git cherry-pick can be useful for undoing changes.
Unlike merge or rebase, cherry-pick lets you select specific source branch commits. For each source branch commit that you cherry-pick, Git creates a corresponding commit on the target branch. You can cherry-pick to tackle these common tasks: Deploy a specific feature from one branch to another.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With