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

Re: git.c option parsing

From
Pierre Habouzit <madcoder@debian.org>
Date
Dec 17, 2007, 09:26 UTC
Message-ID
<20071217092656.GE7453@artemis.madism.org>
In-Reply-To
<20071217092013.GD7453@artemis.madism.org>
On Mon, Dec 17, 2007 at 09:20:13AM +0000, Pierre Habouzit wrote:
Show 27 quoted lines
>   There is a simple way to do that, that wouldn't conflict with the git
> grep -e one, that would be to define an array of "Special" flags, in a
> macro, and have every builtin using parseopt adding that macro at the
> end.
> 
>   Then in git.c, you would have to scan for the command name when called
> through `git --opt1 --opt2 foo`, and pass it to parseopt with as argc
> the position of `foo` in the argument array. Parseopt will trust you for
> it, and if it returns a non zero count, you have to barf, then you just
> need to work on the rest of the array. That would mean in pseudo code
> that this would work like:
> 
>     // ...
>     /* when in `git --opt1 --opt2 foo -a -b -c` mode: */
>     int cmd_pos = git_find_builtin_command_name(argc, argv);
>     int count = parse_options(cmd_pos, argv, git_generic_options,
> 	"git [special-options] cmd [options]", 0);
>     if (count)
> 	die("unknown git command: `%s`", argv[0]);
>     argv += cmd_pos;
>     argc -= cmd_pos;
>     /* here we simulate an argv of {"foo", "-a", "-b", "-c"} */
> 
>   Of course this only works on builtins that do support parseopt other
> ones will need the massage you describe. For them the sole thing to
> change would be to replace the OPT_END() with a GIT_SPECIAL_OPTS() or
> sth alike.
  Oh and I forgot to say that I find this is a brilliant idea, because
there is quite a _lot_ of options that are very pervasive: --quiet,
--verbose, … are pretty obvious candidates, but things like:
`--abbrev=12` does make a lot of sense to me, and it would factor quite
a lot of option structures :) Okay `git --abbrev=12 status` probably
makes no real sense, but who cares ?
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Previous: Pierre HabouzitNext: Pierre Habouzit
Message 10 of 24 in “diff topic tweaks”
  1. 0/3 diff topic tweaksWincent Colaiuta, Dec 14, 2007
  2. 1/3 Revert changes and extend diff option documentationWincent Colaiuta, Dec 14, 2007
  3. 2/3 Use shorter error messages for whitespace problemsWincent Colaiuta, Dec 14, 2007
  4. 3/3 Test interaction between diff --check and --exit-codeWincent Colaiuta, Dec 14, 2007
  5. Junio C HamanoDec 16, 2007
  6. git.c option parsing (was: [PATCH 1/3] Revert changes and extend diff option documentation)Wincent Colaiuta, Dec 17, 2007
  7. Junio C HamanoDec 17, 2007
  8. Wincent ColaiutaDec 17, 2007
  9. Pierre HabouzitDec 17, 2007
  10. Pierre HabouzitDec 17, 2007
  11. Have a flag to stop the option parsing at the first argument.Pierre Habouzit, Dec 17, 2007
  12. Johannes SchindelinDec 17, 2007
  13. Wincent ColaiutaDec 17, 2007
  14. Pierre HabouzitDec 17, 2007
  15. Johannes SchindelinDec 17, 2007
  16. Wincent ColaiutaDec 17, 2007
  17. Johannes SchindelinDec 17, 2007
  18. Wincent ColaiutaDec 17, 2007
  19. Johannes SchindelinDec 17, 2007
  20. Wincent ColaiutaDec 17, 2007
  21. Johannes SchindelinDec 17, 2007
  22. Wincent ColaiutaDec 17, 2007
  23. Johannes SixtDec 17, 2007
  24. Pierre HabouzitDec 17, 2007

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.