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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 7, 2020, 17:58 UTC
Message-ID: <xmqqh7xvtby2.fsf@gitster.c.googlers.com>
In-Reply-To: <CABPp-BGFinonZJb2u_0-fX3y_UyJ1dY+O40oN0WAzZht0ddJ4w@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 14 quoted lines

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