On Sat, 28 May 2011, Junio C Hamano wrote: > 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. Makes sense. I think someone once suggested to have a .git/inprogress directory that would contain some basic information that could be used to diagnose in a generic way what operation might be in progress. > 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. Maybe the recent patch [1] about adding information to git status about any ongoing operation would help. I'm not sure, but I think I would personally be a bit hesitant to cancel the current sequence operation without first checking what it was. OTOH, if I don't even remember starting a rebase operation, maybe knowing whether it was a rebase or an am operation might not help much. But if the message from git status would actually say something like "rebase in progress: [2/3] War on nbsp: a bit of retreat", then that might help more in making a decision to cancel or not. [1] http://thread.gmane.org/gmane.comp.version-control.git/172919 -- 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