Re: rebase -p confusion in 1.6.1

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 15, 2009, 16:04 UTC
Message-ID: <alpine.DEB.1.00.0901151658060.3586@pacific.mpi-cbg.de>
In-Reply-To: <496F4BF0.6020805@drmicha.warpmail.net>

Hi,

On Thu, 15 Jan 2009, Michael J Gruber wrote:

Show 9 quoted lines

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

The intention was this:

	$ git rebase -p master

would need to rewrite _all_ commits that are in "master..". All of them, including the merge commits.

The fact that I implemented it as "-i -p" is only due to technical reasons; I know (ahem, now I should put that into the past tense) the code base pretty well.

An additional shortcut was to avoid rewriting commits when they did not need rewriting. IOW if the commit-to-pick has only parents that were _not_ rewritten, we can avoid cherry-picking or merging, and just reset --hard <original commit>.

There was a problem, though; for some reason, the code as I did it fscked up the order of the commits when -p was specified. Therefore, rewritten commits had the wrong parents.

I thought it should be easy to fix, but then I got a job that I actually like, so my Git time budget was tremendously reduced.

Show 5 quoted lines

> > The more I think about it, I think it's possible I broke it with the 
> > introduction of the "noop".
> 
> It certainly worked after the noop introduction before the r-i-p series, 
> but not any more after.

Umm... which rebase -i -p series do you mean? "noop" was introduced pretty recently if my Alzheimered brain does not fool me.

Ciao, Dscho