Re: rebase -p confusion in 1.6.1

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Jan 15, 2009, 14:45 UTC
Message-ID: <496F4BF0.6020805@drmicha.warpmail.net>
In-Reply-To: <alpine.DEB.1.00.0901151518520.3586@pacific.mpi-cbg.de>

Johannes Schindelin venit, vidit, dixit 15.01.2009 15:25:

Show 20 quoted lines

> Hi,
> 
> On Thu, 15 Jan 2009, Michael J Gruber wrote:
> 
>> Stephan Beyer venit, vidit, dixit 15.01.2009 14:55:
>>
>>>> First of all: git 1.6.0.6 gives you the unchanged graph after using
>>>> rebase -i -p.
>>> This is true and it is a far better behavior than now, but I think it's
>>> not the expected behavior. (I have written about the behavior I'd expect
>>> in another reply to the original mail.)
>> Yep, I think -p should preserve only merges in side branches
> 
> you mean everything in master..work?
> 
>> (and therefore produce what you suggest, and what you get without -p). 
>> If it preserves all merges then there is nothing to rewrite here.
> 
> The merge _is_ outside of master, so I do not understand what the heck you 
> are talking about.

Easy Dscho, easy ;) [meaning "take it such..."]

I'm not sure what -p is supposed to do:

A) Should it preserve all merge commits which it would need to rewrite? That is lot to ask. Previous behaviour (intended or not) seemed to be to do nothing in this case where the merge connects master and work.

B) Should it preserve only merges in side branches? I seem to mean by that branches where the parents are on work and other branches but not on master.

So at least on my side there is confusion about the intention behind '-p' (say design goal), and therefore about the expectation.

Show 5 quoted lines

> The more I think about it, I think it's possible I broke it with the 
> introduction of the "noop".
> 
> However, there could be a _different_ test case where the current -p 
> handling shows the same error.  Dunno.

It certainly worked after the noop introduction before the r-i-p series, but not any more after. "worked" meaning it at least didn't leave out commits in this case (but reproduced the existing DAG). I'm getting the impression you suggest R.I.P. for r-i-p series ;) Fine with me...

Cheers, Michael