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