Re: Bug Report: "git reset --hard" does not cancel an on-going rebase

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 31, 2020, 23:11 UTC
Message-ID: <xmqqimcye7gu.fsf@gitster.c.googlers.com>
In-Reply-To: <34B7EFB9-8710-4993-ACCD-604313D543E7@gmail.com>

Thomas Bétous <th.betous@gmail.com> writes:

Show 9 quoted lines

> I would like to report an inconsistent behavior of the
> rebase/reset commands. I don’t know whether it is an actual bug
> or something else but according to me something is not right.
> When a rebase gets paused (because of a conflict for instance) I
> would expect the command "git reset --hard" to cancel this
> on-going rebase but it does not.  I expect this because for
> instance "git reset --hard" cancels a cherry-pick in the same use
> case so I think the behavior of these 2 commands should be
> consistent.

It is reasonable and desirable for multi-commit operations like "rebase", "cherry-pick A..B" and "revert A..B" not to abort the entire sequence with a mere "reset --hard". After a step resulted in conflicts, the user may try to resolve them, getting into too deep a hole by botching resolution, and wish to redo the current step from scratch, and "reset --hard" can be a way to clean the slate before recreating the same conflict. To abort the whole thing, "rebase --abort" and "cherry-pick --abort" would be needed to differentiate from the "clean this single step" request made with "reset --hard".

On the other hand, operations on a single commit like "cherry-pick X" does not have to retain "what to do after we have dealt with the current step", so "reset --hard" that finishes the whole thing (after all, the whole thing is the single step that may have conflicted) would just be a convenient short-hand.