[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Bug Report: "git reset --hard" does not cancel an on-going rebase
From:       Junio C Hamano <gitster () pobox ! com>
Date:       2020-08-31 23:11:45
Message-ID: xmqqimcye7gu.fsf () gitster ! c ! googlers ! com
[Download RAW message or body]

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

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

[prev in list] [next in list] [prev in thread] [next in thread]