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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 7, 2021, 01:29 UTC
Message-ID: <xmqqa6hdb3sx.fsf@gitster.g>
In-Reply-To: <584bbe43.e.17d926d909f.Coremail.pwxu@coremail.cn>

Aleen 徐沛文 <pwxu@coremail.cn> writes:

Show 8 quoted lines

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