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

["Aleen 徐沛文" <pwxu@coremail.cn>]

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;


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