The previous cherry-pick is now empty when not cherry-picking

Question

I am trying to drop a list of commits by using git rebase -i HEAD~19. I have successfully used this method in the past, but when I try running and then quitting vim without any changes(:q!) I get this error:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git cherry-pick --skip'
interactive rebase in progress; onto dd0b851

I am not cherry picking and not sure why I'm getting an error to skip.

rebase is just batching up one flavor of cherrypick or another, interactive rebase actually uses cherrypick itself. — jthill, Apr 05 '22 at 21:36

score 5 · Answer 1 · answered Apr 05 '22 at 22:18

This is happening because you aren't doing what you think you're doing:

but when I try running and then quitting vim without any changes(:q!)...

When you quit without modifying that file, you are actually still doing the rebase. If you want to exit without doing the rebase, you should delete all the lines in the file (or at least every line that contains a commit on it), and then save and exit. This will display an error and abort the rebase.

The reason just exiting usually works, and appears to do nothing, is because when your history is linear, by default Git won't rewrite a commit if nothing at all about the commit has changed, so it keeps the original commit ID and moves on. This is why you still see "rebasing 1/X..." as it iterates through all the commits and doesn't actually re-write them.

If you history is not linear (meaning you have some merge commits included in the rebase), the merge commits are not included in the to-do list. So this time rebasing will actually rewrite at least some of the commits, because you are missing the merge commits in this rewrite so the graph isn't identical. During the rebase, if it encounters a commit with no changes in it, you will get the message you saw. It stops here because this is considered unusual and it gives you the opportunity to decide what to do. The reason it mentions cherry-pick is because behind the scenes, rewriting commits during a rebase is essentially doing a cherry-pick of each commit for you.

Side Note: the most likely reason that you would have empty commits in this situation is when you have a similar commit on both sides of a merge commit (which is missing from the rebase to-do list).

The previous cherry-pick is now empty when not cherry-picking

1 Answers1