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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
