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

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Nov 30, 2010, 07:56 UTC
Message-ID: <4CF4AE49.7090406@drmicha.warpmail.net>
In-Reply-To: <7v7hfv3mli.fsf@alter.siamese.dyndns.org>

Junio C Hamano venit, vidit, dixit 29.11.2010 21:23:

Show 27 quoted lines

> Michael J Gruber <git@drmicha.warpmail.net> writes:
> 
>> 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.

I don't care too much about the naming. But if I specify a correct string value for "cvsimport.r" (correct as in correct for "-r", lower case!) and "git cvsimport" gives me

fatal: bad config value for 'cvsimport.r' in .git/config

then I call this a bug, notwithstanding the fact that cvsimport does use the value from cvsimport.r for "-r" and continues its operation.

This occurs really without even any attempt at specfiying values for upper case options.

Show 15 quoted lines

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

Well, cvsimport does not have any long options now, and given the fact that most cvsimport related activity lately has been on documenting its shortcomings and promoting cvs2git, I consider that scenario highly unlikely. (I'm not hooked on cvsimport - it's simply the only *incremental* cvs-to-git importer that I know of, and the only one not requiring local access.)

How about using a naming scheme like:

[cvsimport]
	r = origin
	capital-r = yes

This would be safe against any possible future long-options, quickly implementable, and we would not have to invent long names now for the existing one-letter options (and thus hindering any future attempts also). Whether this is more or less ugly lies in the eye of the s/beholder/maintainer/ :)

Michael