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

On Tue, Nov 30, 2021 at 5:42 PM Aleen 徐沛文 [off-list ref] wrote:

quoted

Please don't, at least not this version.  There have been newer
submissions with three commits.

I also still find the word 'die' confusing, since to me it suggests
aborting the whole am operation, and the documentation does not dispel
that concern.  Even if you don't like 'ask' (for consistency with
git-rebase), I think 'stop' or 'interrupt' would be much better
options than 'die'.  If you really want it to be 'die', I think the
behavior needs to be explained in the documentation, rather than just
assumed that users will understand it (because I didn't understand it
until I read the code).

Dears Newren,

    I don't think 'stop' and 'interrupt' words are better to explain more than 'die'
    because they still indicate that it will stop or interrupt the whole am session,
    rather than stop in the middle of it.

Since you've been through several rounds of revisions already, if this
is the only remaining issue with your series, I wouldn't try to hold
it up for this issue; I just thought it could be fixed while you were
working on the --allow-empty stuff.

However, while I don't think it's worth holding up your series for
just this issue, I would definitely submit a follow-up RFC patch to
fix the wording, because I do disagree with your assertion here pretty
strongly.  Let's look at the meanings of the terms:

die: connotes something pretty final and irreversible -- people tend
not to revive after death as far as recorded history goes; most such
recorded instances tend to be causes for people to debate the
definition of 'dead'.

stop: could be final, but is often used in a transitory setting: "stop
and go traffic", "stopped to catch my breath",  "the train will stop
at this station", "stop! I want to get out", etc.

interrupt: seems to nearly always be used as a transitory thing

Now, in the computer science context, all three terms come up relative
to processes.  You can interrupt a process (the kernel does all the
time), but it'll usually continue afterwards.  Or you can give it a
SIGINT (interrupt from keyboard signal), which the process can catch
and ignore.  You can stop a process (and SIGSTOP cannot be caught),
but you can also continue it later.  die essentially means the process
is going to be gone for good (at least short of some kind of black
magic like a reversible debugger such as rr).

So, I think it's much more likely that 'die' will be misunderstood to
mean abortion of the entire am-process, than that 'stop' or
'interrupt' would.

    It may be a good choice to just add an
    additional description about the behaviour when not passing the '--empty' option
    or passing '--empty=die'.

That would be good.