Subject: Re: What's cooking in git.git (Nov 2021, #07; Mon, 29)

From: Junio C Hamano <[email-masked]>
Date: Mon, 06 Dec 2021 17:29:34 -0800

Aleen 徐沛文 <[email-masked]> 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.