[PATCH] commit: add --allow-empty flag

[Ryan McElroy]

On 5/8/2015 10:41 AM, Pierre-Yves David wrote:
>
>
> On 05/07/2015 03:10 PM, Durham Goode wrote:
>> # HG changeset patch
>> # User Durham Goode <durham at fb.com>
>> # Date 1431034538 25200
>> #      Thu May 07 14:35:38 2015 -0700
>> # Node ID 9f90e53f8e810db2d6b0e4cf66433166c4d42934
>> # Parent  c5d4f9cc8da7bb2068457e96e4f74ff694514ced
>> commit: add --allow-empty flag
>
> I'm -1 on adding the new flag and +1 on the ability in core.
>
> Given that apparently multiple users exists for that and that 
> conversion from other VCS requires it, it makes sense to make it 
> somewhat available.
>
> However it is still far too much a corner case to be a first class 
> citizen. Moreover, the most probable usage of that are automation who 
> do not really care about the extra hurdle of going through something 
> more complicated.
> Commit is an important user facing command and its option tend to 
> trickle down to a lot of other commands. In my opinion. This feature 
> is not generic/useful for normal user enough to justify a dedicated flag.
>
> I would go for a config option probably in the [ui] section.
>
> As Augie mentioned, we also have to make sure 
> rebase/graft/histedit/etc preserve them.
>
>
I don't like the idea of having it as a config option, and [ui] doesn't 
seem like that right place for it anyway. Reasons against a config 
option: as a user, this is something that you want to enable on a 
per-command basis. Having it as a ui option implies stickiness is 
desired, but that is generally not the case here (in my experience using 
this functionality in git -- which I used not-as-rarely-as-you-would-think).

The preservation of empty commits after rebases seems like an 
interesting concern, and it's absolutely unclear to me what the right 
choice there is. What are the arguments towards changing the current 
behavior? I think it would be more confusing to have some commits that 
stick around when empty after rebase and others that don't.

I guess this is all a long way of saying that I don't think we should 
block on rebase/histedit supporting this because it's non-obvious that 
they should. And I think the feature should be a flag, perhaps hidden 
from default help (I don't care about that so much right now).