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
Jonathan Nieder <jrnieder@gmail.com>
Date
Nov 20, 2018, 01:09 UTC
Message-ID
<20181120010911.GA62243@google.com>
In-Reply-To
<CAPL8ZivQGGrxjerGxd_R42mJ2XCi_fFcOji3PL0=pWRAZ_OJQQ@mail.gmail.com>
Hi,
Stefan Xenos wrote:
Show 33 quoted lines
> But since several comments have focused on the commands, let's brainstorm!
>
> Here's some options that occur to me:
>
> 1. Three commands: evolve + change + obslog as top-level commands (the
> current proposal). Change gets a bunch of subcommands for manipulating
> the change graph and metas/ namespace.
>
> 2. All top-level: evolve + lschange + mkchange + rmchange +
> prunechange + obslog. None of the commands get subcommands.
>
> 3. Everything under change: "change evolve", "change obslog" become
> new change subcommands.
>
> 4. Evolve as a rebase argument, obslog as a log argument. Use "rebase
> --evolve" to initiate evolve and use "log --obslog" to initiate
> obslog. The change command stays as it is in the proposal.
>
> 5. Two commands: evolve + change. obslog becomes a "log" argument.
>
> Note that there will be more "evolve"-specific arguments in the
> future. For most transformations that evolve uses, there will be a
> matching argument to enable or disable that transformation and as we
> add transformations we'll also add arguments.
>
> If we go with option 3, it would make for a very cluttered help page.
> For example, if you're looking for information on how to use evolve,
> you'd have to scroll past a bunch of formatting information that are
> only relevant to obslog... and if you're looking for the formatting
> options, you'd have to scroll past a bunch of
> transformation-enablement options that are only relevant to evolve.
>
> Based on your log feedback above, I'm thinking #5 may make sense.
(5) sounds good to me, too.  Thanks, both, for your thoughtfulness.
Jonathan
Previous: Stefan XenosNext: Ævar Arnfjörð Bjarmason
Message 6 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.