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

Hi,

On Tue, 27 Jan 2009, Stephen Haberman wrote:

quoted

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.

quoted

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