rebase -i might leave CHERRY_PICK_HEAD behind

* rebase -i might leave CHERRY_PICK_HEAD behind
@ 2015-06-16 12:06 SZEDER Gábor
  2015-06-16 14:56 ` Johannes Schindelin
  2015-06-17  8:15 ` [PATCH 0/2] rebase -i: Fix left-behind CHERRY_PICK_HEAD Johannes Schindelin
  0 siblings, 2 replies; 20+ messages in thread
From: SZEDER Gábor @ 2015-06-16 12:06 UTC (permalink / raw)
  To: git

Hi,

When skipping an empty commit with 'git rebase --continue' a
CHERRY_PICK_HEAD file might be left behind.

What I did boils down to this:

     echo one >file
     git add file
     git commit -m first
     echo two >file
     git commit -a -m second
     echo three >file
     git commit -a -m third
     git rebase -i HEAD^^
     # change todo list to edit the "second" commit

     echo three >file
     git commit -a --amend
     # this effectively makes the third commit an empty commit
     # and rebase will ask what to do:
     git rebase --continue
     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 reset'
     rebase in progress; onto 7335bbe7a5
     You are currently rebasing branch 'master' on '7335bbe7a5'.

     nothing to commit, working directory clean
     Could not apply d19f82ac6d467247117fd734ed039b03ef923c86... third

     # I didn't want an empty commit, but didn't read that carefully, so I did:
     git rebase --continue
     Successfully rebased and updated refs/heads/master.
     # and was rewarded for my lack of attention with the following  
bash prompt:
     test/rebase-empty-continue (master|CHERRY-PICKING)$
     # indeed:
     ls -l .git/CHERRY_PICK_HEAD
     -rw-r--r-- 1 szeder szeder 41 Jun 16 13:22 .git/CHERRY_PICK_HEAD

On one hand, it's user error: it told me to run 'git reset' to achive
what I want but I didn't.
Note, however, how it told me about 'git reset': while 'git commit
--allow-empty' is greatly emphasized by indentation and empty lines
before and after, 'git reset' blends in quite well into the rebase
progress.  It was late, I was tired, and there was a questionable
penalty on Copa América as well ;), so I simply didn't notice.

On the other hand,

    1. 'git rebase' claimed that "Successfully rebased...", yet it left
       cruft behind.  I think it shouldn't.
    2. 'git rebase --continue' didn't complain by the lack of prior
       'git reset' and finished doing exacly what I expected from it to
       do (except leaving CHERRY_PICK_HEAD behind, of course).
       Perhaps it should complain, like it does when the worktree is
       dirty.
       Alternatively, it could just continue to DWIM, as it does
       already, but then it should remove CHERRY_PICK_HEAD as well.

Gábor

^ permalink raw reply	[flat|nested] 20+ messages in thread