From: Junio C Hamano Date: Mon, 02 Aug 2010 21:28:31 GMT Subject: Re: [PATCH 4/5 v4] log: parse detached options like git log --grep foo Message-ID: <7vsk2wk8lc.fsf@alter.siamese.dyndns.org> In-Reply-To: Matthieu Moy writes: > Junio C Hamano writes: > >> The patch overall looks good, and this comments illustrates the issue >> rather well. When the user wants to use "--longopt val" syntax, s/he >> needs to know that "--longopt" will always take a value. Arguably >> majority of options that can take value will, but like "--stat X,Y" this >> leaves things inconsistent. Without "--longopt value" patch there won't >> be such an inconsistency, but I think this patch series is lessor of two >> evils. > > ... especially when parse-option already does this: > > git commit --message foo => works > git gc --prune 'last week' => doesn't > > Just like most GNU tools: > > grep --regexp foo => works > grep --color auto => doesn't Hmm. Are you hinting that we should keep "you can say '-Ofoo' and '-O foo'" bits but we should drop "you can also say '--opt=foo' and '--opt foo' as long as --opt always takes an argument"? I actually think that may make sense. >> Don't you by the way regret the naming of the parsing function by now? >> There is nothing "diff" about it anymore. > > Right. I'll rename them to "parse_long_opt". Thanks.