From: "SZEDER Gábor" <szeder@ira.uka.de>
To: git@vger.kernel.org
Subject: rebase -i might leave CHERRY_PICK_HEAD behind
Date: Tue, 16 Jun 2015 14:06:12 +0200 [thread overview]
Message-ID: <20150616140612.Horde.a1irZQmh2o42SqDfxAytHg1@webmail.informatik.kit.edu> (raw)
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
next reply other threads:[~2015-06-16 12:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 12:06 SZEDER Gábor [this message]
2015-06-16 14:56 ` rebase -i might leave CHERRY_PICK_HEAD behind Johannes Schindelin
2015-06-17 8:15 ` [PATCH 0/2] rebase -i: Fix left-behind CHERRY_PICK_HEAD Johannes Schindelin
2015-06-17 8:16 ` [PATCH 1/2] t3404: demonstrate CHERRY_PICK_HEAD bug Johannes Schindelin
2015-06-17 17:33 ` Junio C Hamano
2015-06-18 11:22 ` Johannes Schindelin
2015-06-18 16:00 ` Junio C Hamano
2015-06-18 16:16 ` Johannes Schindelin
2015-06-17 8:16 ` [PATCH 2/2] rebase -i: do not leave a CHERRY_PICK_HEAD file behind Johannes Schindelin
2015-06-17 12:58 ` SZEDER Gábor
2015-06-17 15:24 ` Johannes Schindelin
2015-06-17 16:43 ` [PATCH 0/2] rebase -i: Fix left-behind CHERRY_PICK_HEAD Junio C Hamano
2015-06-18 11:44 ` [PATCH v2 " Johannes Schindelin
2015-06-18 11:44 ` [PATCH v2 1/2] t3404: demonstrate CHERRY_PICK_HEAD bug Johannes Schindelin
2015-06-18 11:44 ` [PATCH v2 2/2] rebase -i: do not leave a CHERRY_PICK_HEAD file behind Johannes Schindelin
2015-06-18 16:38 ` [PATCH v3 0/2] rebase -i: Fix left-behind CHERRY_PICK_HEAD Johannes Schindelin
2015-06-18 16:38 ` [PATCH v3 1/2] t3404: demonstrate CHERRY_PICK_HEAD bug Johannes Schindelin
2015-06-18 16:38 ` [PATCH v3 2/2] rebase -i: do not leave a CHERRY_PICK_HEAD file behind Johannes Schindelin
2015-06-18 19:45 ` [PATCH v3 0/2] rebase -i: Fix left-behind CHERRY_PICK_HEAD Junio C Hamano
2015-06-18 20:11 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150616140612.Horde.a1irZQmh2o42SqDfxAytHg1@webmail.informatik.kit.edu \
--to=szeder@ira.uka.de \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.