(+cc: Ram) Martin von Zweigbergk wrote: > 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. [...] >> 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). Sorry for the lack of clarity. That actually sounds fine to me already, as long as the intermediate state is easy to recover from (which doesn't match what I usually think of as "undefined behavior"). So it sounds like I was worrying needlessly. [...] >> 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. I believe a good rule of thumb is that you can always pretend the sequencer just doesn't exist, and cc Ram when you are unsure. :) Certainly, a lot of sequencer features were inspired by "git rebase". Improvements to "git rebase" are only likely to make future improvements to "git sequencer" easier. Part of what helps here is that "git rebase" is a shell script, so it is a little easier to prototype features there. Thanks! Jonathan -- 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