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

From: Stephen Haberman <stephen@exigencecorp.com>
Date: Jan 28, 2009, 03:39 UTC
Message-ID: <20090127213950.3596ecf9.stephen@exigencecorp.com>
In-Reply-To: <alpine.DEB.1.00.0901280225240.3586@pacific.mpi-cbg.de>

Show 13 quoted lines

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

Show 7 quoted lines

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