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

Re: [PATCH] technical doc: add a design doc for the evolve command

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 19, 2018, 04:15 UTC
Message-ID
<xmqqwop9d7oq.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<CAPL8ZisfhNqN3gh0E_=mwXuBPGRZ9fKgyQ=HWNFx_9m2job-=g@mail.gmail.com>
Stefan Xenos <sxenos@google.com> writes:
Show 5 quoted lines
> The scenario you describe would not produce an origin edge in the
> metacommit graph. If the user amended X, there would be no origin
> edges - just a replacement. If you cherry-picked Z you'd get no
> replacements and just an origin. In neither case would you get both
> types of parent.
OK, that makes things a lot simpler.

I can see why we want to record "commit X obsoletes commit Y" to help the "evolve" feature, which was the original motivation this started the whole discussion. But it is not immediately obvious to me how it would help to have "Z was cherry-picked from W" in "evolve".

The whole point of cherry-picking an old commit W to produce a new commit Z is because the developer wanted to use the change between W^ and W in a context that is quite different from W^, so it would make no sense to "evolve" anything that was built on top of W on top of Z.

It is of course OK to build a different feature that can take advantage of the cherry-pick information on top of the same meta commit concept in later steps, and to ensure that is doable, the initial meta commit design must be done in a way that is flexible enough to be extended, but it is not clear to me if this "origin" thing is "while this does not have much to do with 'evolve', let's throw in fields that would help another feature while we are at it" or "in addition to 'X obsoletes Y', we need the cherry-pick information for 'evolve' feature because..." (and because it is not clear, I am assuming that it is the former). If we can design the "evolve" thing with only the "contents" and "obsoletes", that would allow us to limit the scope of discussion we need to have around meta commit and have something that works earlier, wouldn't it?

Thanks.
Previous: Junio C HamanoNext: Stefan Xenos
Message 26 of 37 in “technical doc: add a design doc for the evolve command”
  1. technical doc: add a design doc for the evolve commandsxenos@google.com, Nov 15, 2018
  2. Johannes SchindelinNov 15, 2018
  3. Stefan XenosNov 17, 2018
  4. SZEDER GáborNov 19, 2018
  5. Stefan XenosNov 19, 2018
  6. Jonathan NiederNov 20, 2018
  7. Ævar Arnfjörð BjarmasonNov 15, 2018
  8. Jonathan NiederNov 20, 2018
  9. Ævar Arnfjörð BjarmasonNov 20, 2018
  10. Stefan XenosNov 20, 2018
  11. Jonathan NiederNov 20, 2018
  12. Stefan XenosNov 20, 2018
  13. Jonathan NiederNov 21, 2018
  14. Stefan XenosNov 21, 2018
  15. Derrick StoleeNov 16, 2018
  16. Stefan XenosNov 17, 2018
  17. Duy NguyenNov 17, 2018
  18. Stefan XenosNov 18, 2018
  19. Stefan XenosNov 18, 2018
  20. Junio C HamanoNov 18, 2018
  21. Junio C HamanoNov 17, 2018
  22. Stefan XenosNov 19, 2018
  23. Junio C HamanoNov 19, 2018
  24. Stefan XenosNov 19, 2018
  25. Junio C HamanoNov 19, 2018
  26. Junio C HamanoNov 19, 2018
  27. Stefan XenosNov 19, 2018
  28. Jonathan NiederNov 19, 2018
  29. Junio C HamanoNov 20, 2018
  30. Stefan XenosNov 20, 2018
  31. Phillip WoodNov 20, 2018
  32. Phillip WoodNov 20, 2018
  33. Stefan XenosNov 20, 2018
  34. technical doc: add a design doc for the evolve commandPhillip Wood, Jan 15, 2019
  35. Phillip WoodNov 20, 2018
  36. Stefan XenosNov 20, 2018
  37. Phillip WoodNov 21, 2018

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.