On Thu, Oct 13, 2011 at 10:26 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Johannes Sixt wrote: > >> Hitting Ctrl-C during git-rebase results undefined behavior. git-rebase is >> a shell script and was never designed to operate in any form of atomicity. >> >> You should have let it run until it stopped. > > Wait, really? That's bad, and unlike most git commands. If Ctrl-C is pressed while the state is being written, it could be left with incomplete information, yes. It has been like that forever I think. I'll put it on my todo list, but it will not be my top priority (and I have very little git time now anyways). > If interrupting the rebase leaves the repository in a state that > > rm -fr .git/rebase-apply > git reset --hard <appropriate commit name> > > cannot recover from, I'd consider it a serious problem. I agree, but I don't know of any way that can happen. Even "git rebase --abort" should always work (in the sense that .git/rebase-[apply|merge] would be deleted), although it will not return to the original branch if some state is missing. > By the way, what happened to the "git rebase --abort-softly" synonym > for "rm -fr .git/rebase-apply" discussed a while ago? I think we simply did not agree on a syntax, but here was also some discussion about future plans for the sequencer. I remember seeing some discussions about making "git reset --hard" remove the sequencer state, but I don't remember the conclusion. It is not clear to me what is ok to implement in git-rebase nowadays and what would just be double work if it needs to be re-implemented in the sequencer. Martin -- 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