Re: Confusing error message in rebase when commit becomes empty

From: Phil Hord <phil.hord@gmail.com>
Date: Jun 11, 2014, 15:44 UTC
Message-ID: <CABURp0rC3yktDiRVQwo9E+x5_wKLnLVRx87ej+m+TyUdBkMpOA@mail.gmail.com>
In-Reply-To: <alpine.DEB.2.00.1406111321090.6307@ds9.cixit.se>

On Wed, Jun 11, 2014 at 8:49 AM, Peter Krefting <peter@softwolves.pp.se> wrote:

Show 20 quoted lines

> 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.

The correct switch for rebase is --keep-empty, but it is too late to choose it once the interactive rebase is underway. I think the correct advice might be something like this:

  You asked to squash this commit and its parent, but doing so would make
  it empty. You can drop this empty commit with "git reset HEAD^" , or you can
  keep it with "git commit --amend --allow-empty".

But I have not tested this.

> Running "git rebase --continue" does work as expected, but perhaps it just shouldn't stop in this case?

What does it mean when you say it worked as expected? Did it leave the empty commit, omit the empty commit, or leave some un-squashed commit? It's not clear to me what --continue _should_ do in this case, but it does seem like the two options here should be

 1. keep the empty commit
 2. drop the empty commit

I would expect "git rebase --skip" to drop the empty commit, but maybe it will "skip" the squash instead. I don't know. Better advice here is certainly needed.