Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html