Re: interrupting "git rebase" (Re: git rebase +)

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Oct 15, 2011, 15:23 UTC
Message-ID: <CAOeW2eFK5vSKmf+nxzD-6yh5CWZRv4WqSerbSXTPtXmtNeNjxg@mail.gmail.com>
In-Reply-To: <20111014052653.GA5052@elie.hsd1.il.comcast.net>

On Thu, Oct 13, 2011 at 10:26 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 8 quoted lines

> 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).

Show 6 quoted lines

> 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