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. >> 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. -- 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