Miles Bader <miles@xxxxxxx> writes:
> Sverre Rabbelier <srabbelier@xxxxxxxxx> writes:
>>> + } else if (!strcmp(arg, "--grep")) {
>>> + add_message_grep(revs, optarg);
>>> + return 2;
>>
>> This one makes a little less sense since to me '--flag' are always
>> booleans, whereas '-m' can take an argument (such as '-m' from 'git
>> commit'.
>
> The fact that --grep requires the "=" is amazingly confusing if you're
> used to standard GNU long-argument parsing (which many standard
> utilities use, and which git's argument syntax is clearly modelled
> after), where both forms are equivalent, and documentation typically
> only refers to the "=" form, but implicitly allows the separate-args
> form.
I think that parseopt allows both sticky (-mfoo, --message=foo) and
non-sticky (-m foo, --message foo) forms, if I remember it correctly
with exception of arguments with *optional* parameters which require
sticky form.
> I'm continually getting tripped up by git's idiosynchratic argument
> parsing, and it's nice to see it getting cleaned up a bit...
I guess that this solution is simpler than moving to parseopt... is
that because log options and diff options crop everywhere? Do
parseopt have no support for sub-parsers, like e.g. argp from libc:
(libc.info.gz)Argp
(libc.info.gz)Argp Children
http://www.gnu.org/s/libc/manual/html_node/Argp-Children.html
--
Jakub Narebski
Poland
ShadeHawk on #git
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html