threads / discuss / 28665

git rebase +

Subject: git rebase +

## tl;dr

7 messages between Oct 13, 2011 and Oct 17, 2011.

replies: 6people: 5as markdown or json

Adam Piatyszek· Oct 13, 2011, 11:48 UTC · lore
Hi,

In the middle of "git rebase --continue" process I hit Ctrl+C today to break this operation. When I tried to replay the same command it errors out with the following problem:

ediap@stsrdt1:src/toolfiles: git rebase --continue Rebasing (2/3)

[Ctrl+C was hit here]

ediap@stsrdt1:src/toolfiles: git rebase --continue /project/dfttools/libexec/git-core/git-rebase--interactive: line 650: /home/ediap/project.git/.git/rebase-merge/author-script: No such file or directory

Is this an expected behavior?

Thanks, /Adam

Johannes Sixt· Oct 13, 2011, 13:21 UTC · re: Adam Piatyszek · lore

Re: git rebase +

Am 10/13/2011 13:48, schrieb Adam Piatyszek:
Show 8 quoted lines
> In the middle of "git rebase --continue" process I hit Ctrl+C today to break
> this operation. When I tried to replay the same command it errors out with the 
> following problem:
> /project/dfttools/libexec/git-core/git-rebase--interactive: line 650: 
> /home/ediap/project.git/.git/rebase-merge/author-script: No such file or 
> directory
> 
> Is this an expected behavior?

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. Then you could have said 'git rebase --abort' (if it didn't complete) or 'git reset --hard ORIG_HEAD' (if it completed).

-- Hannes
Jonathan Nieder· Oct 14, 2011, 05:26 UTC · re: Johannes Sixt · lore

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

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.
> Then you could have said 'git
> rebase --abort' (if it didn't complete) or 'git reset --hard ORIG_HEAD'
> (if it completed).
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.

By the way, what happened to the "git rebase --abort-softly" synonym for "rm -fr .git/rebase-apply" discussed a while ago?

Jonathan Nieder· Oct 14, 2011, 05:29 UTC · re: Jonathan Nieder · lore

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

Jonathan Nieder wrote:
> By the way, what happened to the "git rebase --abort-softly" synonym
> for "rm -fr .git/rebase-apply" discussed a while ago?
(Here's a pointer I should have included[1].  Sorry for the noise.)
[1] http://thread.gmane.org/gmane.comp.version-control.git/174655
Martin von Zweigbergk· Oct 15, 2011, 15:23 UTC · re: Jonathan Nieder · lore

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

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
Jonathan Nieder· Oct 15, 2011, 19:44 UTC · re: Martin von Zweigbergk · lore

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

(+cc: Ram) Martin von Zweigbergk wrote:

> On Thu, Oct 13, 2011 at 10:26 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Johannes Sixt wrote:
>>> Hitting Ctrl-C during git-rebase results undefined behavior.
[...]
Show 6 quoted lines
>> 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.
[...]
Show 9 quoted lines
>> 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

Ramkumar Ramachandra· Oct 17, 2011, 10:03 UTC · re: Jonathan Nieder · lore

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

Hi,
Jonathan Nieder writes:
Show 13 quoted lines
> Martin von Zweigbergk wrote:
>> On Thu, Oct 13, 2011 at 10:26 PM, Jonathan Nieder <jrnieder@gmail.com> 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).
> [...]
Ah, yes.  I've been bitten by this behavior several times myself :)
Show 15 quoted lines
>>> 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.
> [...]
> 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.

I concur. Work on `git rebase` should continue independently of the sequencer because that's where we pick up ideas from! I don't see it as double-work: simply a translation of ideas. Apart from the fixup mini-series, the overall interface of the sequencer is still very unclear to me (see long discussion with Junio, Jonathan).

Yes, 95eb88 (reset: Make reset remove the sequencer state, 2011-08-04) is merged. But it's pretty unrelated to the main issue at hand: sure, "reset --hard" is a great hammer, but that shouldn't prevent us from developing tools and interfaces that are more sophisticated and elegant, no? In other words, I think "--abort-softly" is a great idea: we should pour ideas into our shell scripts!

Thanks.
-- Ram

← back to recent threads