Aleen 徐沛文 [off-list ref] writes:
Dears Hamano,
In my opinion, the '--empty' should act as a strategy option like the
'X' option to 'git-rebase'. Since that the default behaviour of not passing
the option is stopped in the middle of an am session, should the 'die' value
dies the whole process but not the middle state? It may also make it not
confusing.
Hmph, unlike "git rebase" or "git merge", "git am" does not employ
different strategy backends, so "-X<option>" would be out of place,
I would think.
Among what we already have, what kills the entire session is called
"git am --abort". Since I do not find it unnatural to say "'git am'
dies" when it stops and gives control back to the user, so that the
user can decide what to do next, I am not sure where the aversion to
the word comes from (on the other hand, I find 'ask' highly
unnatural since we do not ask anything---we just throw the control
back the user).
The confusing point seems why "git am" stops into the middle and gives
control back to the user when passing "die". In common cases, "die"
should stop the whole process, and is it better to distinguish the case
when passing "die" from the default behaviour? Like what the following
snippet is implemented:
case ERR_EMPTY_COMMIT:
printf_ln(_("Patch is empty.\n"
"If you want to record it as an empty commit, run \"git am --allow-empty\"."));
die_user_resolve(state);
case DIE_EMPTY_COMMIT:
am_destroy(state);
die(_("Patch is empty."));
break;
quoted
Dears Hamano,
In my opinion, the '--empty' should act as a strategy option like the
'X' option to 'git-rebase'. Since that the default behaviour of not passing
the option is stopped in the middle of an am session, should the 'die' value
dies the whole process but not the middle state? It may also make it not
confusing.
Hmph, unlike "git rebase" or "git merge", "git am" does not employ
different strategy backends, so "-X<option>" would be out of place,
I would think.
Among what we already have, what kills the entire session is called
"git am --abort". Since I do not find it unnatural to say "'git am'
dies" when it stops and gives control back to the user, so that the
user can decide what to do next, I am not sure where the aversion to
the word comes from (on the other hand, I find 'ask' highly
unnatural since we do not ask anything---we just throw the control
back the user).
case ERR_EMPTY_COMMIT:
printf_ln(_("Patch is empty.\n"
"If you want to record it as an empty commit, run \"git am --allow-empty\"."));
die_user_resolve(state);
Sorry for the missing "break" here.
case DIE_EMPTY_COMMIT:
am_destroy(state);
die(_("Patch is empty."));
break;
On Sun, Dec 5, 2021 at 10:28 PM Junio C Hamano [off-list ref] wrote:
Aleen 徐沛文 [off-list ref] writes:
quoted
Dears Hamano,
In my opinion, the '--empty' should act as a strategy option like the
'X' option to 'git-rebase'. Since that the default behaviour of not passing
the option is stopped in the middle of an am session, should the 'die' value
dies the whole process but not the middle state? It may also make it not
confusing.
Hmph, unlike "git rebase" or "git merge", "git am" does not employ
different strategy backends, so "-X<option>" would be out of place,
I would think.
Among what we already have, what kills the entire session is called
"git am --abort". Since I do not find it unnatural to say "'git am'
dies" when it stops and gives control back to the user, so that the
user can decide what to do next, I am not sure where the aversion to
the word comes from
When I first read the documentation, it sounded to me like it was
implying an abort. I find 'die' very unnatural as a way to explain
this behavior; it's too strong of a word.
(on the other hand, I find 'ask' highly
unnatural since we do not ask anything---we just throw the control
back the user).
Okay, but what about my previous suggestions of 'stop' or 'interrupt'?