Re: git.c option parsing
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