From: Jakub Narebski Date: Tue, 27 Jul 2010 10:24:51 GMT Subject: Re: [RFC PATCH 1/2] Allow "git log --grep foo" as synonym for "git log --grep=foo". Message-ID: In-Reply-To: Miles Bader writes: > Sverre Rabbelier 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