Re: Heads up: rebase -i -p will be made sane again

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 27, 2009, 17:59 UTC
Message-ID: <alpine.DEB.1.00.0901271855240.3586@pacific.mpi-cbg.de>
In-Reply-To: <20090127085418.e113ad5a.stephen@exigencecorp.com>

Hi,

On Tue, 27 Jan 2009, Stephen Haberman wrote:

Show 26 quoted lines

> > As for the design bug I want to fix: imagine this history:
> > 
> >   ------A
> >  /     /
> > /     /
> > ---- B
> > \     \
> >  \     \
> >   C-----D-----E = HEAD
> > 
> > A, C and D touch the same file, and A and D agree on the contents.
> > 
> > Now, rebase -p A does the following at the moment:
> > 
> >   ------A-----E' = HEAD
> >  /     /
> > /     /
> > ---- B
> > 
> > In other words, C is truly forgotten, and it is pretended that D never 
> > happened, either.  That is exactly what test case 2 in t3410 tests for 
> > [*1*].
> > 
> > This is insane.
> 
> Agreed.

Good!  I already feared that you would be disagreeing with me.

> Does this mean you're just getting rid of the code that calls "rev list 
> --cherry-pick"?

Not exactly. The idea of rebasing is to stay on top of an upstream. If that upstream has your changes already, you do not want to reapply them -- even with --preserve-merges.

Now, a merge cannot be sent as a patch mail, for good reasons. So whatever merge might look like yours, it is not. So it is your responsibility to say that yours is obsolete, and delete it from the rebase script.

If your merge is in upstream (because a pull-request was heeded, for example), then you will not see the commits anyway.

> A few times I've pondered just removing the --cherry-pick/drop commit 
> part of rebase-p, but assumed it was there for a reason.

I will find the "dropped" commits using git log -p | git patch-id.

It is still nice to tell the user if she wants to merge a parent that is already in upstream, so I would not like to miss out on that information.

Show 15 quoted lines

> > [*1*] The code in t3410 was not really easy to read, even if there was 
> > an explanation what it tried to do, but the test code was inconsitent, 
> > sometimes tagging, sometimes not, sometimes committing with -a, 
> > sometimes "git add"ing first, yet almost repetitive.
> > 
> > In my endeavor not only to understand it, and either fix my code or 
> > the code in t3410, I refactored it so that others should have a much 
> > easier time to understand what it actually does.
> 
> Thanks for cleaning it up.
> 
> I recently saw a test of yours use a `test_commit` bash function that I 
> really like. My last patch submission debacle had a patch cleaning up 
> t3411 by introducing `test_commit`--I can brave `git send-email` again 
> if you have any interest in me resending it.

Heh... so I sent that part of the patches. Hopefully they will get in soon, as they should be rather obvious, and I have a lot more to come...

Ciao, Dscho