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

Re: [PATCH v2 1/3] builtin/commit-graph.c: support '--split[=<strategy>]'

From
Taylor Blau <me@ttaylorr.com>
Date
Feb 9, 2020, 23:30 UTC
Message-ID
<20200209233042.GE4530@syl.local>
In-Reply-To
<CAN0heSrXZd7ktBTHaYFWjhW=NcGx5gL52-unSDaC4ZoNf96HFA@mail.gmail.com>
On Thu, Feb 06, 2020 at 08:41:28PM +0100, Martin Ågren wrote:
Show 22 quoted lines
> On Wed, 5 Feb 2020 at 01:28, Taylor Blau <me@ttaylorr.com> wrote:
> > diff --git a/Documentation/git-commit-graph.txt b/Documentation/git-commit-graph.txt
> > index 28d1fee505..b7fe65ef21 100644
> > --- a/Documentation/git-commit-graph.txt
> > +++ b/Documentation/git-commit-graph.txt
> > @@ -57,11 +57,17 @@ or `--stdin-packs`.)
> >  With the `--append` option, include all commits that are present in the
> >  existing commit-graph file.
> >  +
> > -With the `--split` option, write the commit-graph as a chain of multiple
> > -commit-graph files stored in `<dir>/info/commit-graphs`. The new commits
> > -not already in the commit-graph are added in a new "tip" file. This file
> > -is merged with the existing file if the following merge conditions are
> > -met:
> > +With the `--split[=<strategy>]` option, write the commit-graph as a
> > +chain of multiple commit-graph files stored in
> > +`<dir>/info/commit-graphs`. Commit-graph layers are merged based on the
> > +strategy and other splitting options. The new commits not already in the
> > +commit-graph are added in a new "tip" file. This file is merged with the
> > +existing file if the following merge conditions are met:
>
> Please add a lone "+" here.
Sure, thanks for noticing.
Show 23 quoted lines
> > +* If `--split=merge-always` is specified, then a merge is always
> > +conducted, and the remaining options are ignored. Conversely, if
> > +`--split=no-merge` is specified, a merge is never performed, and the
> > +remaining options are ignored. A bare `--split` defers to the remaining
> > +options.
> >  +
>
> Similar to this existing one here. There's some minor misrendering here
> otherwise.
>
> >  * If `--size-multiple=<X>` is not specified, let `X` equal 2. If the new
> >  tip file would have `N` commits and the previous tip has `M` commits and
>
> > -               OPT_BOOL(0, "split", &opts.split,
> > -                       N_("allow writing an incremental commit-graph file")),
> > +               OPT_CALLBACK_F(0, "split", &split_opts.flags, NULL,
> > +                       N_("allow writing an incremental commit-graph file"),
> > +                       PARSE_OPT_OPTARG | PARSE_OPT_NONEG,
> > +                       write_option_parse_split),
>
>
> I keep getting back to this -- sorry! So this actually forbids
> "--no-split", which used to work before. Unfortunate?

Ah, I see. Yes, this definitely *does* forbid that. My thinking when I decided to give this 'PARSE_OPT_NONEG' was that '--no-split' is confusing for users: does it mean "don't split" or "unset any split options"?

This probably would be ameliorated by your suggestion below, maybe of '--split-strategy', specifically (I could probably go either way on '--format=split', but it really depends on what Stolee has planned long-term). Then, '--[no-]split' remains clear, as does '--no-split-strategy' (although I suppose that you could make the argument that '--no-split-strategy' sounds a little bit like letting the machinery use its defaults, which may or may not be true depending on how it's implemented.)

But, I'm not sure that it's all worth it to add another option here. This sub-builtin has a plethora of options already, and I'm skeptical that there are a lot of real-world uses of '--no-split' in the wild that we'd be breaking.

Show 13 quoted lines
> I have to ask, what is the long-term plan for the two formats (split and
> non-split)? As I understand it, and I might well be wrong, the non-split
> format came first and the split format was a user-experience
> improvement. Should we expect that `--split` becomes the default? In
> which case `--no-split` would be needed. Or might the non-split format
> go away entirely, leaving `--split` a no-op and `--split=<strategy>` a
> pretty funky way of choosing a strategy for the one-and-only file
> format?
>
> To try to be concrete, here's a suggestion: `--format=split` and
> `--split-strategy=<strategy>`.
>
> Martin

Thanks, Taylor

Previous: Taylor BlauNext: Taylor Blau
Message 41 of 58 in “builtin/commit-graph.c: new split/merge options”
  1. 0/3 builtin/commit-graph.c: new split/merge optionsTaylor Blau, Jan 31, 2020
  2. 1/3 builtin/commit-graph.c: support '--split[=<strategy>]'Taylor Blau, Jan 31, 2020
  3. Derrick StoleeJan 31, 2020
  4. Taylor BlauFeb 4, 2020
  5. Martin ÅgrenJan 31, 2020
  6. Taylor BlauFeb 4, 2020
  7. Martin ÅgrenFeb 6, 2020
  8. Taylor BlauFeb 9, 2020
  9. SZEDER GáborJan 31, 2020
  10. Johannes SchindelinFeb 1, 2020
  11. SZEDER GáborFeb 3, 2020
  12. Jeff KingFeb 3, 2020
  13. Taylor BlauFeb 4, 2020
  14. Jeff KingFeb 4, 2020
  15. Taylor BlauFeb 4, 2020
  16. Taylor BlauFeb 4, 2020
  17. 2/3 builtin/commit-graph.c: introduce '--input=<source>'Taylor Blau, Jan 31, 2020
  18. Derrick StoleeJan 31, 2020
  19. Taylor BlauFeb 4, 2020
  20. Martin ÅgrenJan 31, 2020
  21. Taylor BlauFeb 4, 2020
  22. SZEDER GáborFeb 13, 2020
  23. SZEDER GáborFeb 13, 2020
  24. Taylor BlauFeb 13, 2020
  25. 3/3 builtin/commit-graph.c: support '--input=none'Taylor Blau, Jan 31, 2020
  26. Derrick StoleeJan 31, 2020
  27. Martin ÅgrenJan 31, 2020
  28. Taylor BlauFeb 4, 2020
  29. Taylor BlauJan 31, 2020
  30. Derrick StoleeJan 31, 2020
  31. Derrick StoleeJan 31, 2020
  32. Junio C HamanoFeb 4, 2020
  33. Taylor BlauFeb 5, 2020
  34. 0/3 builtin/commit-graph.c: new split/merge optionsTaylor Blau, Feb 5, 2020
  35. 1/3 builtin/commit-graph.c: support '--split[=<strategy>]'Taylor Blau, Feb 5, 2020
  36. Martin ÅgrenFeb 6, 2020
  37. Derrick StoleeFeb 7, 2020
  38. Taylor BlauFeb 9, 2020
  39. Martin ÅgrenFeb 12, 2020
  40. Taylor BlauFeb 12, 2020
  41. Taylor BlauFeb 9, 2020
  42. 2/3 builtin/commit-graph.c: introduce '--input=<source>'Taylor Blau, Feb 5, 2020
  43. 3/3 builtin/commit-graph.c: support '--input=none'Taylor Blau, Feb 5, 2020
  44. Martin ÅgrenFeb 6, 2020
  45. Taylor BlauFeb 9, 2020
  46. Junio C HamanoFeb 5, 2020
  47. 0/3 builtin/commit-graph.c: new split/merge optionsTaylor Blau, Feb 12, 2020
  48. 1/3 builtin/commit-graph.c: support '--split[=<strategy>]'Taylor Blau, Feb 12, 2020
  49. 2/3 builtin/commit-graph.c: introduce '--input=<source>'Taylor Blau, Feb 12, 2020
  50. 3/3 builtin/commit-graph.c: support '--input=none'Taylor Blau, Feb 12, 2020
  51. SZEDER GáborFeb 13, 2020
  52. SZEDER GáborFeb 13, 2020
  53. Junio C HamanoFeb 13, 2020
  54. Taylor BlauFeb 13, 2020
  55. Taylor BlauFeb 13, 2020
  56. Junio C HamanoFeb 12, 2020
  57. Taylor BlauFeb 13, 2020
  58. Martin ÅgrenFeb 17, 2020

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.