Re: [PATCH 1/2] remote: add camel-cased *.tagOpt key, like clone

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

I wondered if we want "git config -l --preserve-case" or something like that, but an extra grep for "tagOpt" would be sufficient in a simple test like these that are unlikely to have unrelated tagOpt defined in the file. More importantly, I am starting to doubt if this should even be tested.

If there were existing "section.varname" variable definition and we ask

	git_config_set("section.varName", "newvalue");

we may end up with "[section] varname = newvalue", and that is perfectly OK, I would think, because the first and the last component of the configuration variable names are defined to be case insensitive, and here may be "[Section] varname = oldvalue" in the configuration file before we try to set it, and the implementation is free to replace "oldvalue" with "newvalue", instead of first removing "[Section] varname = oldvalue" and then adding a new "[section] varName = newvalue" (after all, there may be variables other than "varname" in the section, and the existing "[Section]" header may need to be kept for the remaining variables while we futz with the varname or varName).

Which means that while we do want to spell the names in our source code correctly (i.e. "tagOpt", not "tagopt") when we tell which variable we want to get modified to the git_config_set() function, we should not care how exactly git_config_set() chooses to spell the variable in the resulting configuration file, no?

So, ...

...as long as "git config remote.origin.tagopt" yields what we expect, we should be OK, I would think. Insisting that the variable name is kept by git_config_set() API may be expecting too much.