Junio C Hamano venit, vidit, dixit 29.11.2010 21:23: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >> Signed-off-by: Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> >> --- >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html