rebase -i might leave CHERRY_PICK_HEAD behind

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]