Junio C Hamano <gitster@xxxxxxxxx> writes: > Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > >> Junio C Hamano <gitster@xxxxxxxxx> 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. I'm not sure I parsed your sentence correctly, but if I did, then no, I don't think we should drop separate forms when --opt always takes an argument, just the opposite. -O<string> => always accepted -O <string> => OK if <string> is mandatory and always non-empty --opt=<sting> => always accepted --opt <string> => OK if <string> is mandatory (possibly empty) My remark was that there's nothing very original here, what my patch does is what other places of Git did, and that other common tools did years before. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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