Re: [RFC] cherry-pick using multiple parents to implement -x

["Stephen R. van den Berg" <srb@cuci.nl>]

Jeff King wrote:
>On Sun, Sep 07, 2008 at 12:34:15PM +0200, Stephen R. van den Berg wrote:

>> The questions now are:
>> - Would there be good reason not to record the backport/forwardport
>>   relationship in the additional parents of a commit?

>Parents mean something different than just a link. If A is a parent of
>B, then that implies that at point B, we considered all of the history
>leading up to B (including A), and arrived at a certain tree state.

That implication is not a technical one, but merely a convention in the
mind of the git-user.  Relevant, of course, but maybe we can accomodate
both uses.

>But cherry-picking means we looked at just A and used it to find a
>certain tree-state. It says nothing about anything that came _before_ A.

Correct.

>Now let's say we want to cherry-pick E. If we mark the cherry-picked
>commit as a parent, we get:

>A--B--C--E' <-- master
> \      /
>  D----E--F <-- side branch

>Now let's say we want to merge the branches. What's our merge base?
>Without your proposal, it is A, but now it is actually E. So doing a
>three-way merge between E' and F with base E, it will look like our
>master branch _removed_ the change from D which is still present in F.
>And in a 3-way merge if one side removes something but the other side
>leaves it untouched, then the result removes it.

>So the merge result is bogus, as it is missing D.

True.  However...

What if the merge-base determination code is modified to behave as
if --first-parent is specified while searching for the merge-base?
In that case it *will* find A as the merge-base, even in the presence of
"sideportlinks".

Does that resolve all technical issues?
-- 
Sincerely,
           Stephen R. van den Berg.

"The future is here, it's just not widely distributed yet." -- William Gibson