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

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

From
Stephen R. van den Berg <srb@cuci.nl>
Date
Sep 7, 2008, 19:56 UTC
Message-ID
<20080907195626.GA8765@cuci.nl>
In-Reply-To
<20080907172807.GA25233@coredump.intra.peff.net>
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
Show 6 quoted lines
>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
Previous: Jeff KingNext: Jeff King
Message 3 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.