Re: [PATCHv2 3/3] cvsimport.txt: document the mapping between config and options

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 29, 2010, 20:23 UTC
Message-ID: <7v7hfv3mli.fsf@alter.siamese.dyndns.org>
In-Reply-To: <317523448870044a68311f811b42bd9461b90d43.1290973138.git.git@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

Show 20 quoted lines

> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
>  Documentation/git-cvsimport.txt |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt
> index 608cd63..b5d5b27 100644
> --- a/Documentation/git-cvsimport.txt
> +++ b/Documentation/git-cvsimport.txt
> @@ -176,6 +176,13 @@ messages, bug-tracking systems, email archives, and the like.
>  -h::
>  	Print a short usage message and exit.
>  
> +CONFIG
> +------
> +For any option '-x' you can set the config variable 'cvsimport.x' to the value
> +you would specify for '-x', or to 'true' for a boolean option. For an
> +uppercase option '-X' use the config variable 'cvsimport.xx' (or
> +'cvsimport.XX').
> +

I still think this is not about fixing "parsing" as 2/3 states but about "working around the initial design flaw of how configuration variables are used in cvsimport" in that the initial design didn't take it into account that the last component of a configuration variable is case insensitive.

While mapping -X to .xx may be a usable workaround, it looks really ugly. Worse, if we are going to give long command line options to the command someday, we will really regret it doing it the way your patch does.

Would it be a better alternative to give conflicting but rarely used uppercase options longer option name synonyms, and have them specified in the gitconfig file in their full names? Then we can disambiguate with something like

    [cvsimport]
    	generate-cvs-revisions = yes
        remote = origin

which would be more readable, no?