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

Re: [PATCH 2/3] builtin/commit-graph.c: introduce '--input=<source>'

From
SZEDER Gábor <szeder.dev@gmail.com>
Date
Feb 13, 2020, 11:33 UTC
Message-ID
<20200213113313.GO10482@szeder.dev>
In-Reply-To
<20200204045124.GG5790@syl.local>
On Mon, Feb 03, 2020 at 08:51:24PM -0800, Taylor Blau wrote:
> On Fri, Jan 31, 2020 at 08:34:41PM +0100, Martin Ågren wrote:
> > On Fri, 31 Jan 2020 at 01:30, Taylor Blau <me@ttaylorr.com> wrote:
> > > The 'write' mode of the 'commit-graph' supports input from a number of
s/mode/subcommand/
> > > different sources:

I note that you use the word "sources" here, in the subject line as well (as '--input=<source>'), and in the code as well (e.g. the in the error message "unrecognized --input source, %s"). I like this word, I think the words "input" and "source" go really well together.

> > > pack indexes over stdin, commits over stdin, commits
> > > reachable from all references, and so on.

It's interesting to see that you stopped listing and went for "and so on" right when it got interesting/controversial with '--append'... :)

> > > Each of these options are
> > > specified with a unique option: '--stdin-packs', '--stdin-commits', etc.

It also supports the very inefficient scanning through all objects in all pack files to find commit objects, which, sadly, ended up being the default, and thus doesn't have its own --option. Should there be a corresponding '--input=<source>' as well? (Note that I don't mean this as a suggestion to add one; on the contrary, the less exposure it gets the better.)

Show 37 quoted lines
> > > Similar to our replacement of 'git config [--<type>]' with 'git config
> > > [--type=<type>]' (c.f., fb0dc3bac1 (builtin/config.c: support
> > > `--type=<type>` as preferred alias for `--<type>`, 2018-04-18)), softly
> > > deprecate '[--<input>]' in favor of '[--input=<source>]'.
> > >
> > > This makes it more clear to implement new options that are combinations
> > > of other options (such as, for example, "none", a combination of the old
> > > "--append" and a new sentinel to specify to _not_ look in other packs,
> > > which we will implement in a future patch).
> >
> > Makes sense.
> >
> > > Unfortunately, the new enumerated type is a bitfield, even though it
> > > makes much more sense as '0, 1, 2, ...'. Even though *almost* all
> > > options are pairwise exclusive, '--stdin-{packs,commits}' *is*
> > > compatible with '--append'. For this reason, use a bitfield.
> >
> > > -With the `--append` option, include all commits that are present in the
> > > -existing commit-graph file.
> > > +With the `--input=append` option, include all commits that are present
> > > +in the existing commit-graph file.
> >
> > Would it be too crazy to call this `--input=existing` instead, and have
> > it be the same as `--append`? I find that `--append` makes a lot of
> > sense (it's a mode we can turn on or off), whereas "input = append"
> > seems more odd.
> 
> Hmm. When I wrote this, I was thinking of introducing equivalent options
> that are identical in name and functionality as '--input=<mode>' instead
> of '--<mode>'. So, I guess that is to say that I didn't spend an awful
> amount of time thinking about whether or not '--input=append' made sense
> given anything else.
> 
> So, I don't think that '--input=existing' is a bad idea at all, but I do
> worry about advertising this deprecation as "'--<mode>' becomes
> '--input=<mode>', except when your mode is 'append', in which case it
> becomes '--input=existing'".

But here you suddenly start using the word "mode" both in '--input=<mode>' and in '--<mode>'.

On one hand, I don't think that the word "mode" goes as well with "input" as "source" does.

On the other, is '--append' really a source/mode, like '--reachable' and '--stdin-commits' are? Source, no: from wordsmithing perspective it doesn't fit with "source", and being orthogonal to the "real" source options while they are mutually exclusive seems to be a clear indication that it isn't. Mode, yes: it's a mode of operation where no longer reachable/present commits are not discarded from the commit-graph.

So I don't think that adding '--input=append' is a good idea, even if we were call it differently, e.g. '--input=existing' as suggested above.

However, I do think that '--input=existing' would better express what '--input=none' in the next patch wants to achieve.

Previous: Taylor BlauNext: SZEDER Gábor
Message 22 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.