On Fri, Jun 13, 2014 at 08:25:43AM +0100, Peter Krefting wrote:
> >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
--
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