With Git 2.23 (Q3 2019), "git cherry-pick/revert" learned a new "--skip" action.
So in your case: git cherry-pick --skip on C.
See commit dcb500d, commit de81ca3, commit 265ab48, commit 918d1e6, commit 6a1f904 (02 Jul 2019) by Rohit Ashiwal (r1walz).
(Merged by Junio C Hamano -- gitster -- in commit d97c62c, 19 Jul 2019)
cherry-pick/revert: add --skip option
git am or rebase have a --skip flag to skip the current commit if the
user wishes to do so.
During a cherry-pick or revert a user could likewise skip a commit, but needs to use 'git reset' (or in the case of conflicts 'git reset --merge'), followed by 'git (cherry-pick | revert) --continue' to skip the commit.
This is more annoying and sometimes confusing on the users' part.
Add a --skip option to make skipping commits easier for the user and to make the commands more consistent.
Update the advice messages, to tell users about this less
cumbersome way of skipping commits.
So instead of seeing:
Otherwise, please use 'git reset
If you wish to skip this commit, use:
git reset
You will see:
Otherwise, please use 'git cherry-pick --skip
and then use:
git cherry-pick --continue
The mechanism to prevent "git commit" from making an empty commit or amending during an interrupted cherry-pick was broken during the rewrite of "git rebase" in C, which has been corrected with Git 2.27 (Q2 2020).
See commit 5b7a64d (06 Dec 2019) by Johannes Schindelin (dscho).
See commit 430b75f, commit 901ba7b, commit 8d57f75, commit 21b11c6, commit f028d66, commit 780308d (06 Dec 2019) by Phillip Wood (phillipwood).
(Merged by Junio C Hamano -- gitster -- in commit f085189, 25 Mar 2020)
commit: give correct advice for empty commit during a rebase
Original-patch-by: Johannes Schindelin
Signed-off-by: Phillip Wood
In dcb500dc16c ("cherry-pick/revert: advise using --skip", 2019-07-02, Git v2.23.0-rc0 -- merge listed in batch #6), git commit learned to suggest to run git cherry-pick --skip when trying to cherry-pick an empty patch.
However, it was overlooked that there are more conditions than just a git cherry-pick when this advice is printed (which originally suggested the neutral git reset): the same can happen during a rebase.
Let's suggest the correct command, even during a rebase.
While at it, we adjust more places in builtin/commit.c that incorrectly assumed that the presence of a CHERRY_PICK_HEAD meant that surely this must be a cherry-pick in progress.
Note: we take pains to handle the situation when a user runs a git cherry-pick during a rebase.
This is quite valid (e.g. in an exec line in an interactive rebase).
On the other hand, it is not possible to run a rebase during a cherry-pick, meaning: if both rebase-merge/ and sequencer/ exist or CHERRY_PICK_HEAD and REBASE_HEAD point to the same commit , we still want to advise to use git cherry-pick --skip.