Re: [PATCH v5] send-email: prompt-dependent exit codes

From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Date: Aug 30, 2023, 10:06 UTC
Message-ID: <ZO8Ut3t2ns1lj/pM@ugly>
In-Reply-To: <xmqq3501bbmf.fsf@gitster.g>

On Tue, Aug 29, 2023 at 05:46:32PM -0700, Junio C Hamano wrote:

Show 14 quoted lines

>Oswald Buddenhagen <oswald.buddenhagen@gmx.de> writes:
>
>> Proposed content for RelNotes:
>>
>>  * "git send-email" now reports interactive cancellation via a distinct
>>    non-zero exit status. Callers which do not consider this situation an
>>    error need to be adjusted.
>
>If we still want to deliberately break folks with this change, we
>should not blame users for becoming accustomed to the traditional
>behaviour and pretend as if burdening them to change their scripts
>is within our rights.  We should be a lot more apologetic in the
>backward compatibility notes than what you wrote in the above.
>

i find this deference mind-boggling.

i'm sure you're somewhat cautious because you're on the frontline when people complain, and *someone* will _always_ complain when things change. however, it's completely unreasonable to let this dictate one's possibilities. there is a trade-off between the cost of change and the cost of non-change.

Show 6 quoted lines

>Given that the users have
>lived with the current behaviour practically forever in Git's
>timescale and that not changing the default and letting them "live
>with" the status quo cannot cause any serious problem, I cannot
>stand behind such a default change myself.
>

the exit code really only matters when there is a wrapper which decides significant follow-up actions based on it (that is, doesn't exit right afterwards anyway). i don't think many such scripts exist for git-send-email. those which do will most likely suppress interaction. which is why nobody else complained yet. and also why likely nobody will complain if we change it. the few people that will notice at all will most likely welcome the change, as i would.

>It should be a new feature that is opt-in,
>

do as you like, but i won't spend the time on roughly doubling the size of the patch, nor on dealing with this being an opt-in (i don't want a hard dep on a new git version in the near term), and i won't contribute to sabotaging the discovery of hidden bugs.

>just like any other new and useful feature..
>

not reporting a significant event is a bug.

>Subject: [PATCH] SQUASH???
>

yes, please.

regards