Re: [PATCH] config: Use parseopt.

Johannes Schindelin [off-list ref] writes:

Maybe I should point out something that is obvious to somebody who 
followed the Git list for a long time: there are two areas of the code 
that had such a track record of regressions that Junio grew a distaste for 
them: git-config and parse options.

There is a difference between them; please don't confuse new readers.

git-config does have a rather unfortunate track record and the code may
still be a mess.  But parse-options itself is a good code overall.  Only
that some of the parse-opt-ification attempts in the past might have been
quite bad.

Parse-opt-ification is an obvious, trivial change with a limited scope,
well-defined end results and clear gain to the end users.  The API exists
so the patch author does not have to invent a new framework, the change a
patch needs will typically be limited to a single command, the set of
options the command needs to accept/reject are already defined, and at the
end you can give unique prefix of flags from the command line.

There may be a correlation between parse-opt-ification attempts and bad
review cycles, but there is no such a causal relationship "parse-opt
patches are bad because parse-opt is a bad idea".  

If there is such a correlation, it is more likely that it is merely
because parse-opt-ification attracted more inexperienced people than
tricker areas like revision traversal or extended SHA-1 syntax.

But people can send bad patches to any area ;-).