On Mon, Dec 17, 2007 at 09:20:13AM +0000, Pierre Habouzit wrote: > 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@xxxxxxxxxx OOO http://www.madism.org
Attachment:
pgprZEe33KNr0.pgp
Description: PGP signature