Git configuration options have a complicated situation with regard to
case. For the most part, they are case-insensitive: you may write any
case into the file, but Git interprets it as lower case. However, there
are exceptions.
Because the middle component of a three-component option can be a URL,
branch name, or remote name, this component (and only this component) is
treated as case sensitive. Since this component can be a URL, which may
(and, due to the ".git" portion, usually does) contain a dot, the first
component of the config option is read up until the first dot, and the
last component is read from the end to the last dot.
When git config writes a value into the file, it preserves the case the
user has provided, and when it prints the config values, it
canonicalizes the keys by folding the case-insensitive portions to
lowercase. Git LFS then reads this canonicalized form in as our source
of config options, relieving us from having to parse the files ourselves.
However, when we read this data in, we forced the key to lowercase, and
when we looked up a key, we also forced the key we were looking up to
lowercase. While this behavior was wrong (since URLs, at least, are
case-sensitive), it did happen to mostly work if the configuration
didn't contain settings for two URLs differing in case.
In the 2.7.0 cycle, we changed the way we did URL config lookups to
match the way Git does them. Previously, we performed configuration
lookups on several possible keys (forcing them to lower case, URL
portion included) and took the first that matched. Now, we directly
compare the URL we're connecting to (which may be in mixed case) to the
values we got in the configuration (which we've forced to lowercase).
Consequently, we will fail to find configuration options for a
mixed-case URL, resulting in things like "http.extraHeader" not being
used.
Fix this issue by letting Git do the canonicalization of configuration
keys for us instead of lowercasing them ourselves and then
canonicalizing the key when looking it up in the table. Add tests for
this behavior with "http.extraHeader" in the integration suite and
several canonicalization assertions in the unit tests. Update several
tests to use the canonical version of the data in their test data
stores, and add a check to avoid noncanonical test data.
Co-authored-by: Taylor Blau <me@ttaylorr.com>
