Aleen 徐沛文 <pwxu@xxxxxxxxxxx> writes:
>> It is my understanding that the ONLY reason the patch proposes to
>> add an option other than "skip the step" and "create an empty
>> commit" is to allow an earlier "--empty=skip" on the command line to
>> be overridden by a later "--empty=die". If that option does not
>> make the command behave identically to "--empty=<anything>" option
>> on the command line, i.e. ERR_EMPTY_COMMIT case, it does not serve
>> the intended purpose of overriding the earlier option to revert the
>> behaviour back to the default.
[jc: do not top-post, as people read from top to bottom]
> I have doubted that since that the default behaviour is that stopping
> when meeting commit messages lacking a patch and giving control back
> to the user, is that necessary to provide duplicated '--empty=die'?
> Should we just provide '--empty=(drop|keep)'?
Adding an option that aborts and trashes the state directory is much
worse than not having a choice other than drop and keep, which is in
turn a bit worse than having a way to countermand an option that was
given earlier on the command line.
If we were to have an option other than drop/keep, as Elijah
suggested, it may make sense to call it "stop" rather than "die" (I
think "ask" is a mistake, as we do not ask anything to the user).
>> By the way, I agree with an earlier comment (I think it was from Dscho)
>> that these names should say "${DO_THIS}_ON_EMPTY_COMMIT"; the above
>> without "ON" feels somewhat strange.
This still stands, too.
Thanks.
