Thomas Bétous <th.betous@xxxxxxxxx> 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.
