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

Jeff King wrote:

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

quoted

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