On Sun, Sep 07, 2008 at 09:56:26PM +0200, Stephen R. van den Berg wrote: > >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. I'm not sure I agree. I believe that property is part of the definition of the commit DAG as originally conceived (but somebody like Linus could say more). Obviously there is no formal definition, but I already pointed out one thing that will break in that instance. I don't know if there are others. > 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". But then it will fail to find legitimate merge bases. So yes, you _can_ come up with a merge algorithm that handles this situation. But is it then up to the user to say "Oh, this parent link means something else. Use this other algorithm"? In that case, it really seems we are abusing the "parent" link and it would be more appropriate to have some _other_ type of link. Though I think if you look through the archives, people have argued against having any git-level link to cherry-picked commits. The history leading up to that cherry-pick is not necessarily of interest (though I think you are proposing that it be optional to create such a link via -x). > Does that resolve all technical issues? I really don't know. I think you are proposing changing a core assumption of the data structure, so I wouldn't be too surprised if there is other code that relies on it. You can use the script I posted in my last email as a basis for a cherry-pick that does what you want (cherry-pick -n, write-tree, commit-tree, update-ref). You might try a few experiments with that. -Peff -- 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
