git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Jeff King <peff@peff.net>
Date
Sep 7, 2008, 20:04 UTC
Message-ID
<20080907200441.GA26705@coredump.intra.peff.net>
In-Reply-To
<20080907195626.GA8765@cuci.nl>
On Sun, Sep 07, 2008 at 09:56:26PM +0200, Stephen R. van den Berg wrote:
Show 7 quoted lines
> >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
Previous: Stephen R. van den BergNext: Stephen R. van den Berg
Message 4 of 25 in “[RFC] cherry-pick using multiple parents to implement -x”
  1. Stephen R. van den BergSep 7, 2008
  2. Jeff KingSep 7, 2008
  3. Stephen R. van den BergSep 7, 2008
  4. Jeff KingSep 7, 2008
  5. Stephen R. van den BergSep 7, 2008
  6. Jeff KingSep 8, 2008
  7. Stephen R. van den BergSep 8, 2008
  8. Junio C HamanoSep 7, 2008
  9. Stephen R. van den BergSep 7, 2008
  10. Thomas RastSep 7, 2008
  11. Junio C HamanoSep 7, 2008
  12. Junio C HamanoSep 7, 2008
  13. Paolo BonziniSep 8, 2008
  14. Junio C HamanoSep 8, 2008
  15. Junio C HamanoSep 7, 2008
  16. Stephen R. van den BergSep 8, 2008
  17. Paolo BonziniSep 8, 2008
  18. Stephen R. van den BergSep 8, 2008
  19. Jakub NarebskiSep 8, 2008
  20. Paolo BonziniSep 8, 2008
  21. Shawn O. PearceSep 8, 2008
  22. Stephen R. van den BergSep 8, 2008
  23. Shawn O. PearceSep 8, 2008
  24. Stephen R. van den BergSep 9, 2008
  25. Paolo BonziniSep 8, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.