Duy Nguyen <pclouds@xxxxxxxxx> writes:
> On Mon, Mar 18, 2019 at 11:54 AM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> I often find "git reset --hard <some other starting point>" after a
>
> It still bugs me that I need to use this to abort some in-progress
> operation.
Note that my comment was *NOT* about aborting the in-progress "am".
What happens in that "I often find" situation is that I identify the
problem's origin, prepare a branch to apply a fix forking from an
old release point that includes the origin, and "am" tells me the
code diverged too much and it cannot be applied, or "am -3" tells me
that the author sent the patch based on some unknown base. At that
point, I "git reset --hard" to some plausible place the author would
have based the patch (e.g. "master" pushed out last night) and then
say "am" or ("am --no-3") to retry.
So your response is unrelated to what I said, but having said that,
it still deserves a comment.
> ... There's "git X --abort" but I would need to find out what X
> is first. I would like "git abort" or something (and "git continue")
> but haven't really thought that through yet. That direction may also
> lead to "git undo" which is another can of worms.
I rarely had "what was I doing" problem; doesn't the command line
prompt tell you? It is debatable (and I am pessimistic) if a
general blanket "git abort" makes sense, but the info on the current
status (i.e. "what was the user doing?") it must gather should be
a strict superset as what is needed to give useful info in the
command line prompt, so a good place to start may be to think about
what's missing (not shown) in the prompt and if that is deliberate
omission (avoiding overly verbose prompt) or is coming from lack of
enough information. Then we may need to do something about the latter
by teaching these commands with state to leave more clue of what we
were in the middle of and what the next step would be.
After thinking about that, the answer might turn out to be to unify
the backend of these commands with state to a single one, or at
least fewer ones, so that we can have better grasp and control over
how these backend engines record state when they give control back
to the user.
