Re: New git-rebase backend: no way to drop already-empty commits

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> Yes, from the manpage:
>
> ...
>
> and
>
> """
> Empty commits
> ~~~~~~~~~~~~~
>
> The apply backend unfortunately drops intentionally empty commits, i.e.
> commits that started empty, though these are rare in practice.  It
> also drops commits that become empty and has no option for controlling
> this behavior.

This is a very good illustration that shows why "switch the default
and retire the apply backend" deserves to be cooked for quite a long
time.  The 'apply' dropping empty commits may have looked like an
'unfortunate' thing to whoever wrote the above paragraph in the
documentation, but it clearly shows that person (me included) did
not think of the ramifications deeply enough that there may be valid
workflows that _depend_ on the behaviour.

As we will be dropping 'apply' that could be used as an escape
hatch, before we do so, we should teach the other backends an
alternate escape hatch to help those who have been depending on the
behaviour of 'apply' that discards the empty ones, whether they
become empty, or they are empty from the beginning.  I think the
"has contents originally but becomes empty" side is already taken
care of, so we'd need to make sure it is easy to optionally discard
the ones that are originally empty.

Thanks.