From: Junio C Hamano Date: Mon, 29 Nov 2010 20:23:53 GMT Subject: Re: [PATCHv2 3/3] cvsimport.txt: document the mapping between config and options Message-ID: <7v7hfv3mli.fsf@alter.siamese.dyndns.org> In-Reply-To: <317523448870044a68311f811b42bd9461b90d43.1290973138.git.git@drmicha.warpmail.net> Michael J Gruber writes: > Signed-off-by: Michael J Gruber > --- > 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?