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

[Stephen Haberman <stephen@exigencecorp.com>]

> Actually, I misread t3410 a great deal.  The situation is as follows:
> 
>     ... UPSTREAM
>            \
> ... A - B - C -D
> 
> A is a patch the upstream does not have, B is a patch UPSTREAM has,
> and "git diff C^!" (i.e. the diff of C to its first parent) is _also_ 
> identical to a diff of a merge that is in UPSTREAM.
> 
> Basically, t3410 tests that after "git rebase -i -p UPSTREAM" and leaving 
> the rebase script as-is, essentially, A and D are cherry-picked on top of 
> UPSTREAM.

Cool--I "knew" that, but could not have articulated the case as
succinctly.

> > Does this mean you're just getting rid of the code that calls "rev list 
> > --cherry-pick"?
> 
> Only now do I understand.
> 
> I misread the code for --cherry-pick.  For merges, it adds the diff to the 
> first parent!

Ah, so that is how --cherry-pick works--I'd never looked into the
patch-id stuff before. Makes sense, both of how it is leveraged by
rev-list --cherry-pick and also that it doesn't make sense to only be
against the first parent of merges.

> So I adapted my code to find the "dropped" merges in
> git-rebase--interactive, too, for now, but I guess the proper fix is
> something like this:

So, if C, as a merge commit, doesn't get a patch id anymore (right?),
does that mean that C is included with A and D in the cherry-picking
on top of UPSTREAM (because with no patch id it cannot be recognized
as a duplicate)? So then C' is an empty-commit? This would be fine, I
think, or can you detect that C is a noop somehow without patch ids?

Thanks,
Stephen