From: Jeff King <peff@peff.net>
To: Peter Krefting <peter@softwolves.pp.se>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Confusing error message in rebase when commit becomes empty
Date: Fri, 13 Jun 2014 03:27:50 -0400 [thread overview]
Message-ID: <20140613072749.GD7908@sigill.intra.peff.net> (raw)
In-Reply-To: <alpine.DEB.2.00.1406111321090.6307@ds9.cixit.se>
On Wed, Jun 11, 2014 at 01:49:04PM +0100, Peter Krefting wrote:
> Hi!
>
> I am rebasing a branch to combine a couple of commits. One is a revert of a
> previous commit. Since there are commits in-between, I do "squash" to make
> sure I get everything, and then add the actual change on top of that. The
> problem is that rebase stops with a confusing error message (from commit,
> presumably):
>
> $ git rebase --interactive
> [...]
> You asked to amend the most recent commit, but doing so would make
> it empty. You can repeat your command with --allow-empty, or you can
> remove the commit entirely with "git reset HEAD^".
> rebase in progress; onto 342b22f
> You are currently rebasing branch 'mybranch' on '342b22f'.
>
> No changes
>
> Could not apply 4682a1f20f6ac29546536921bc6ea0386441e23e... Revert "something"
>
> OK, so I should retry the command with --allow-empty, then:
>
> $ git rebase --interactive --allow-empty
> error: unknown option `allow-empty'
>
> Nope, that's not quite right.
Yeah, that message comes from "commit --amend", which is called by
rebase to handle the squash. The "repeat your command" part is
confusing. The right thing to do here is:
git commit --amend --allow-empty
if you want to have an empty commit, or:
git reset HEAD^
if you want to have nothing.
Of course the first one would never occur to you, because it is not
"your command" in the first place. :)
We could change it to say "use git commit --amend --allow-empty", though
that is slightly incomplete for other cases (e.g., you might have
actually said "git commit --amend -a", and the right advice is to
include that "-a".
Commit understands a "whence" flag that could let it customize the
message for the case of rebase. But I think you would have to teach
determine_whence to figure out that we are in a rebase.
> Running "git rebase --continue" does work as expected, but perhaps it just
> shouldn't stop in this case?
As you noticed later in the thread, doing "--continue" omits the revert.
That's because it is telling rebase "OK, I've fixed this up, we can keep
going". But of course it wasn't fixed.
prev parent reply other threads:[~2014-06-13 7:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 12:49 Confusing error message in rebase when commit becomes empty Peter Krefting
2014-06-11 15:44 ` Phil Hord
2014-06-11 17:57 ` Peter Krefting
2014-06-11 19:04 ` Phil Hord
2014-06-13 7:25 ` Peter Krefting
2014-06-13 7:31 ` Jeff King
2014-06-13 7:27 ` Jeff King [this message]
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=20140613072749.GD7908@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=peter@softwolves.pp.se \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).