Re: [PATCH] config: Use parseopt.

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 15, 2009, 02:22 UTC
Message-ID: <7vab8oqw09.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0902142213090.10279@pacific.mpi-cbg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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 ;-).