Re: [RFC PATCH 1/2] Allow "git log --grep foo" as synonym for "git log --grep=foo".

[Jakub Narebski <jnareb@gmail.com>]

Miles Bader <miles@gnu.org> writes:
> Sverre Rabbelier <srabbelier@gmail.com> 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