Jeff King <p...@peff.net> writes: > On Thu, Feb 16, 2017 at 11:30:28AM +0100, Lars Schneider wrote: > >> >> > On 16 Feb 2017, at 00:48, Junio C Hamano <gits...@pobox.com> wrote: >> > >> > The "git -c <var>=<val> cmd" mechanism is to pretend that a >> >> The problem is also present for gitconfig variables e.g. >> git config --local submodule.UPPERSUB.update none > > Hrm, is it? > > $ git config --file foo submodule.UPPERSUB.update none > $ cat foo > [submodule "UPPERSUB"] > update = none > > I could believe that some of the submodule code may try to pass it > through "-c", though, so certain config ends up being missed.
You are right. The builtin/config.c::get_value() codepath, when it is not using the hacky regexp interface, uses config.c::git_config_parse_key(), and it does the right thing. git_config_parse_parameter(), which is the broken one we found, is not used. When I did the patch in response to Jonathan's observation, I did briefly wonder if it should be using git_config_parse_key() instead of doing its own thing, but I didn't follow it up fully before deciding that it is the quickest to replace the tolower thing. If I at least tried to see if it is feasible, I would have noticed that the query from the command line wouldn't share the same problem as Lars reported. I still haven't queued any of the variants I posted (and I do not think other people sent their own versions, either). I need to pick one and queue, with a test or two. Perhaps after -rc2. Others are welcome to work on it while I cut -rc2 tomorrow, so that by the time I see their patch all that is left for me to do is to apply it ;-)
