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

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Stephen R. van den Berg <srb@...>
Cc: <git@...>
Date: Sunday, September 7, 2008 - 4:04 pm

On Sun, Sep 07, 2008 at 09:56:26PM +0200, Stephen R. van den Berg wrote:


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.


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


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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Sun Sep 7, 6:34 am)
Re: [RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Mon Sep 8, 7:51 am)
Re: [RFC] cherry-pick using multiple parents to implement -x, Shawn O. Pearce, (Mon Sep 8, 10:38 am)
Re: [RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Mon Sep 8, 10:58 am)
Re: [RFC] cherry-pick using multiple parents to implement -x, Shawn O. Pearce, (Mon Sep 8, 11:00 am)
Re: [RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Tue Sep 9, 4:51 am)
Re: [RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Mon Sep 8, 9:42 am)
Re: [RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Sun Sep 7, 4:10 pm)
Re: [RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Sun Sep 7, 3:56 pm)
Re: [RFC] cherry-pick using multiple parents to implement -x, Jeff King, (Sun Sep 7, 4:04 pm)
Re: [RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Sun Sep 7, 4:22 pm)
Re: [RFC] cherry-pick using multiple parents to implement -x, Stephen R. van den Berg, (Mon Sep 8, 2:57 am)