Re: [PATCH] rebase: learn --discard subcommand

[Junio C Hamano <gitster@pobox.com>]

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

> ... I think Junio then
> hinted that he sometimes wished that he could abort rebase without
> moving to anywhere else at all, which is what this patch implements.

I am not opposed to this particular patch, but thinking about a bigger
picture, I am not sure if we want to solve it this way.

We have multiple "sequence" operations that want to do things in multiple
steps, each of which can stop and give control back to the user, while
leaving some information in the .git directory for it to know where it was
when resuming. I think "am" knows about what "rebase" does (and
vice-versa) so it can detect an attempt to run it while "rebase" is in
still progress and refuse to continue to limit the damage, but if we have
N such "sequence" commands that want to refrain from interfering with each
other, and want to offer an advice to abort the in-progress operation
initiated by other commands, that would mean we would need N * N pieces of
logic to detect other's in-limbo state and offer advices, which would not
scale.

A user who is given back the control from a "sequence" operation may be
confused either (1) immediately after such an event (often some sort of
merge conflict) or (2) much later after first abandoning the working tree
altogether and taking a walk and then coming back to continue working
while forgetting what he was doing. Such a user may want to say "I know I
am in a strange state, give me a state that I can work from, at this point
I do not care about continuing what I was originally doing". The user may
probably not know if "git rebase" was in progress or "git cherry-pick"
was.

"git reset --hard" used to be such a command in simpler times. It removes
MERGE_HEAD unconditionally, so that a confused user can start from scratch
without having to worry about what was in progress. As a devil's advocate,
I am wondering if it is a good idea to simply teach "reset --hard" to also
remove any and all "sequence" cruft (.git/rebase-apply, .git/rebase-merge,
CHERRY_PICK_HEAD; we might have others I do not recall offhand) and be
done with it. It is a large hammer, but it is certainly the easiest to
explain and the simplest to understand way to get out of any troubles.