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

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

Michael J Gruber [off-list ref] writes:

quoted

Signed-off-by: Michael J Gruber <redacted>
---
 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.

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