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:20 UTC
Message-ID
<20071217092013.GD7453@artemis.madism.org>
In-Reply-To
<25018761-80E8-410C-BB18-DD799F58308A@wincent.com>
On Mon, Dec 17, 2007 at 09:01:56AM +0000, Wincent Colaiuta wrote:
Show 28 quoted lines
> El 17/12/2007, a las 9:48, Junio C Hamano escribió:
> 
> >Wincent Colaiuta <win@wincent.com> writes:
> >
> >>Of course, the above plan will only work for builtins, not for
> >>scripts. An additional step would be needed to enable scripts to
> >>handle these options; perhaps teaching "git rev-parse" something...
> >
> >As long as special options stay special and we make a rule not to allow
> >any subcommand to assign its own meaning to them, the git wrapper can
> >lookahead and reorder, when seeing a command line:
> >
> >	git scripted-command --special
> >
> >into
> >
> >	git --special scripted-command
> >
> >And that approach would work well for built-ins as well, I would
> >imagine.
> 
> Yes, and it would be simpler to implement also. The only downside is that 
> without all the other proposed changes things like "git-dashed --special" 
> wouldn't work; only teaching the builtins to actually handle the special 
> options would work in that case. And in the interests of consistency I 
> think it's pretty important that "git subcommand --special" and 
> "git-subcommand --special" both work the same as the user would 
> (reasonably) expect them to...
  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.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org
Previous: Wincent ColaiutaNext: Pierre Habouzit
Message 9 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.