On Tue, Apr 7, 2020 at 10:58 AM Junio C Hamano [off-list ref] wrote:

Elijah Newren [off-list ref] writes:

quoted

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.

I wonder if the existing --empty could be extended, such that "drop"
was treated as a (deprecated?) synonym for "drop-new" (a new entry in
the list), with a new "drop-all". That way end users could pass
--empty=drop-all to get the old "apply" behavior with "merge".
Something like "--empty={drop-all,drop-new[,drop],keep,ask}::". A name
like "drop-all" seems more obvious/intuitive than simply "all" or
"always".

Just a thought from someone else who was also bitten by this behavior change.

Thanks.