git rebase +

git rebase +

[Adam Piatyszek]

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

Re: git rebase +

[Johannes Sixt]

Am 10/13/2011 13:48, schrieb Adam Piatyszek:
> 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

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

[Jonathan Nieder]

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?

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

[Jonathan Nieder]

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

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

[Martin von Zweigbergk]

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

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

[Jonathan Nieder]

(+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.
[...]
>> 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

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

[Ramkumar Ramachandra]

Hi,

Jonathan Nieder writes:
> 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 :)

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