Re: Confusing error message in rebase when commit becomes empty

From: Jeff King <peff@peff.net>
Date: Jun 13, 2014, 07:31 UTC
Message-ID: <20140613073113.GE7908@sigill.intra.peff.net>
In-Reply-To: <alpine.DEB.2.00.1406130823251.27436@ds9.cixit.se>

On Fri, Jun 13, 2014 at 08:25:43AM +0100, Peter Krefting wrote:

Show 9 quoted lines

> >Yes, but empty commits are discouraged on some projects.  If you want your
> >"change + revert = empty" commit to appear after the squash, I would
> >expect you would want to use --keep-empty on your inital rebase command.
> >But I'm not sure that will do what you expected either; it may only keep
> >previously-empty commits during the rebase.
> 
> The thing is that I wasn't expecting it to come out empty, as I had another
> commit to squash into it. That the interim throw-away squashed commit was
> empty should have been an internal matter to rebase, IMHO.

That's a good point that I neglected in my other response. Maybe the right solution is for "rebase --interactive" to always pass "--allow-empty" when doing a squash. And then either:

  1. Always keep such empty commits. A user who is surprised by them
     being empty can then revisit them. Or drop them by doing another
     rebase without --keep-empty.

  2. Notice ourselves that the end-result of the whole squash is an
     empty commit, and stop to let the user deal with it.

-Peff