Re: [BUG?] rebase -i -p leaves index changed

From: Stephan Beyer <s-beyer@gmx.net>
Date: Aug 13, 2008, 20:51 UTC
Message-ID: <20080813205103.GB10758@leksak.fem-net>
In-Reply-To: <200808121116.41535.trast@student.ethz.ch>

Hi,

Thomas Rast wrote:

Show 15 quoted lines

> 'rebase -i -p' appears to be a bit confused about what it is doing.
> Try a history like this:
> 
>   O -- A -- M -- B
>    \       /
>     \- C -/
> 
> built by:
> 
>   git init
>   touch foo
>   git add foo
>   git ci -m initial
>   git tag root
>   git co -b side

Puh, it is nice that you provide a sequence how you generated your test case, but "ci" and "co" are no git commands. Ok, because of the sequence it was clear to me that you mean "commit" and "checkout", but I couldn't just c&p it into my xterm :( ;-)

> Second, 'edit' is also a bit suspicious:
> 
>   git reset --hard
>   GIT_EDITOR='perl -i -pe "s/pick 096/edit 096/"' git rebase -i -p root

This perl expression does nothing if your commit is not prefixed with 096 ;) But I tested by changing the line of commit "a" to "edit".

> Despite claiming "Stopped at 096[...] a", a quick 'git show' tells us
> that it is actually stuck at 'initial'.  (At least 'git rebase
> --continue' then ends up with the same result as the first test.)

Regarding your [BUG?]: this is a bug, definitely.

> Granted, I'm not entirely sure what it _should_ do.  In my use case
> (relating to the filter-branch topic), C was a commit from elsewhere
> that B depended on.  So I kind of hoped 'rebase -i -p' would let me
> edit A, then rebuild M and B on top, while leaving C alone.

I think your hope is right.  So this is also a bug.

I tested this with my sequencer-based rebase -i -p first and it worked as you hope. I tested it with your v2 patches and it works, too. ;) So I'm having a deeper look at your patches in some minutes...

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F