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

Re: [PATCH] builtin/config.c: prefer `--type=bool` over `--bool`, etc.

From
Jeff King <peff@peff.net>
Date
Mar 30, 2018, 18:27 UTC
Message-ID
<20180330182713.GA30349@sigill.intra.peff.net>
In-Reply-To
<xmqqmuyp4kqi.fsf@gitster-ct.c.googlers.com>
On Fri, Mar 30, 2018 at 09:00:05AM -0700, Junio C Hamano wrote:
Show 27 quoted lines
> Jeff King <peff@peff.net> writes:
> 
> > ... But actually, last-one-wins applies only
> > to a _single_ option, not necessarily unrelated ones. Many other
> > multi-action commands actually have a series of separate boolean flags,
> > and then complain when more than one of the flags is set.
> >
> > So maybe it's not such a good idea for the actions (I do still think
> > it's the right path for the types).
> 
> If this were using command verbs (e.g. "git config get foo.bar") as
> opposed to command options (e.g. "git config --get foo.bar"), it
> wouldn't ahve allowed multiple command verbs from the command line,
> and last-one-wins would not have made much sense because there is no
> way to trigger it as a desirable "feature".
> 
> Just like the topic of the discussion unifies --int/--bool/etc. into
> a single --type={int,bool,...}, perhaps the existing command options
> --get/--list/etc. can be taken as if they were a mistaken historical
> way to spell --action={get,list,...}.  I of course am not recommending
> to add a new "--action" option.  I am suggesting it as a thought-aid
> to see if actions are all that different from value type options.
> 
> I agree that a-bit-per-type that is checked with HAS_MULTI_BITS()
> for error at the end does not make much sense.  I also think what
> you did in this patch for actions is a good clean-up for the above
> reason.

I agree the code internally is nicer after the patch. If we throw away the argument of "last-one-wins is more consistent with other parts of git" (because I don't really think that it is for this type of option), I could possibly buy this as a code cleanup. But it does have a user-visible impact, which makes the question: are we _OK_ with switching to last-one-wins?

-Peff
Previous: Junio C HamanoNext: Taylor Blau
Message 7 of 60 in “builtin/config.c: prefer `--type=bool` over `--bool`, etc.”
  1. builtin/config.c: prefer `--type=bool` over `--bool`, etc.Taylor Blau, Mar 28, 2018
  2. Junio C HamanoMar 29, 2018
  3. Jeff KingMar 29, 2018
  4. Taylor BlauMar 30, 2018
  5. Jeff KingMar 30, 2018
  6. Junio C HamanoMar 30, 2018
  7. Jeff KingMar 30, 2018
  8. 1/2 builtin/config.c: treat type specifiers singularlyTaylor Blau, Mar 30, 2018
  9. 2/2 builtin/config.c: prefer `--type=bool` over `--bool`, etc.Taylor Blau, Mar 30, 2018
  10. René ScharfeMar 30, 2018
  11. Jeff KingMar 30, 2018
  12. Jeff KingMar 30, 2018
  13. 0/2 builtin/config.c: prefer `--type=bool` over `--bool`, etc.Taylor Blau, Apr 4, 2018
  14. 1/2 builtin/config.c: treat type specifiers singularlyTaylor Blau, Apr 4, 2018
  15. Eric SunshineApr 4, 2018
  16. Taylor BlauApr 5, 2018
  17. Jeff KingApr 5, 2018
  18. 2/2 builtin/config.c: prefer `--type=bool` over `--bool`, etc.Taylor Blau, Apr 4, 2018
  19. Eric SunshineApr 4, 2018
  20. Taylor BlauApr 5, 2018
  21. 0/2 builtin/config.c: prefer `--type=bool` over `--bool`, etc.Taylor Blau, Apr 5, 2018
  22. Jeff KingApr 5, 2018
  23. Taylor BlauApr 5, 2018
  24. 0/2 builtin/config.c: support `--type=<type>` as preferred alias for `--type`Taylor Blau, Apr 6, 2018
  25. 0/2 builtin/config.c: support `--type=<type>` as preferred alias for `--type`Taylor Blau, Apr 9, 2018
  26. Eric SunshineApr 9, 2018
  27. 0/2 builtin/config.c: support `--type=<type>` as preferred alias for `--type`Taylor Blau, Apr 11, 2018
  28. Junio C HamanoApr 11, 2018
  29. Taylor BlauApr 11, 2018
  30. Junio C HamanoApr 11, 2018
  31. Taylor BlauApr 11, 2018
  32. 0/2 builtin/config.c: support `--type=<type>` as preferred alias for `--type`Taylor Blau, Apr 18, 2018
  33. 1/2 builtin/config.c: treat type specifiers singularlyTaylor Blau, Apr 5, 2018
  34. 2/2 builtin/config.c: prefer `--type=bool` over `--bool`, etc.Taylor Blau, Apr 5, 2018
  35. Jeff KingApr 5, 2018
  36. Taylor BlauApr 5, 2018
  37. Taylor BlauApr 6, 2018
  38. 2/2 builtin/config.c: prefer `--type=bool` over `--bool`, etc.Taylor Blau, Apr 5, 2018
  39. Eric SunshineApr 5, 2018
  40. Jeff KingApr 5, 2018
  41. Taylor BlauApr 6, 2018
  42. Taylor BlauApr 6, 2018
  43. 1/2 builtin/config.c: treat type specifiers singularlyTaylor Blau, Apr 6, 2018
  44. 2/2 builtin/config.c: support `--type=<type>` as preferred alias for `--type`Taylor Blau, Apr 6, 2018
  45. Eric SunshineApr 6, 2018
  46. Taylor BlauApr 7, 2018
  47. Eric SunshineApr 7, 2018
  48. 1/2 builtin/config.c: treat type specifiers singularlyTaylor Blau, Apr 9, 2018
  49. Junio C HamanoApr 10, 2018
  50. Taylor BlauApr 10, 2018
  51. Eric SunshineApr 10, 2018
  52. 2/2 builtin/config.c: support `--type=<type>` as preferred alias for `--type`Taylor Blau, Apr 9, 2018
  53. Junio C HamanoApr 10, 2018
  54. Taylor BlauApr 10, 2018
  55. 1/2 builtin/config.c: treat type specifiers singularlyTaylor Blau, Apr 11, 2018
  56. 2/2 builtin/config.c: support `--type=<type>` as preferred alias for `--type`Taylor Blau, Apr 11, 2018
  57. 1/2 builtin/config.c: treat type specifiers singularlyTaylor Blau, Apr 18, 2018
  58. 2/2 builtin/config.c: support `--type=<type>` as preferred alias for `--type`Taylor Blau, Apr 18, 2018
  59. Junio C HamanoApr 19, 2018
  60. Taylor BlauApr 19, 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.