Menu
I have been trying to use
git log --no-merges --cherry-pick --right-only master...my-branch to generate a list of commits that are in the my-branch, but not in master (as per the git-log documentation). However, there are still many equivalent commits that are coming up in the list. If I show them and their patches, there is no difference apart from the commit id.
git show 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 >patcha git show c53c7c32dcd84bfa7096a50b27738458e84536d5 >patchb diff patcha patchb 1c1 < commit 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 --- > commit c53c7c32dcd84bfa7096a50b27738458e84536d5 And even git patch-id shows them as being equivalent:
git show c53c7c32dcd84bfa7096a50b27738458e84536d5 | git patch-id 2b5504fb9a8622b4326195d88c7a20f29701e62b c53c7c32dcd84bfa7096a50b27738458e84536d5 git show 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 | git patch-id 2b5504fb9a8622b4326195d88c7a20f29701e62b 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 How does git log --cherry-pick not pick these up as duplicates?
910
This makes it useful for undoing changes, however, it's noteworthy to remember that cherry-picking will NOT delete the commit that was cherry-picked from the feature branch, so you will have to create a new feature branch and cherry-pick all your commits once more without the bug fix.
A cherry-pick is basically a commit, so if you want to undo it, you just undo the commit. Stash your current changes so you can reapply them after resetting the commit.
Can you cherry pick multiple commits in Git? It is possible to cherry pick multiple commits using the command line. Git 1.7. 2 introduced the ability to cherry pick a range of commits.
git cherry pick can also be passed some execution options. The --no-commit option will execute the cherry pick but instead of making a new commit it will move the contents of the target commit into the working directory of the current branch.
Have you merged master into your branch since doing the cherry picks? --cherry-pick works first by matching the commit id, and then if that fails, looking for the patch id. If you've merged master into your branch, then you'll now have the actual commit on your branch and the cherry-picked version. So it'll find the commit id, and then proceed to report the cherry-picked version.
I've often wondered if git should always check both, but that's probably a considerable performance hit.
149
I've often wondered if git should always check both, but that's probably a considerable performance hit.
That behavior is now (Git 2.11, Q4 2016) quicker than before.
See commit 7c81040 (12 Sep 2016), and commit 5a29cbc (09 Sep 2016) by Jeff King (peff).
Helped-by: Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit f0a84de, 21 Sep 2016)
patch-ids: refuse to computepatch-idfor merge commit
"
git log --cherry-pick" used to include merge commits as candidates to be matched up with other commits, resulting a lot of wasted time. The patch-id generation logic has been updated to ignore merges to avoid the wastage.
[...] we may spend a lot of extra time computing these merge diffs.
In the case that inspired this patch, a "git format-patch --cherry-pick" dropped from over 3 minutes to less than 3 seconds.
And with Git 2.31 (Q1 2021), it is fixed: when more than one commit with the same patch ID appears on one side, "git log --cherry-pick A...B"(man) now does exclude them all when a commit with the same patch ID appears on the other side.
21
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
