Re: [PATCH v3] config: add support for http.<url>.* settings

[Aaron Schrab <aaron@schrab.com>]

At 06:07 -0700 12 Jul 2013, "Kyle J. McKay" <mackyle@gmail.com> wrote:
>I don't think it's necessary to split the URL apart though.  Whatever 
>URL the user gave to git on the command line (at some point even if 
>it's now stored as a remote setting in config) complete with URL-
>encoding, user names, port names, etc. is the same url, possibly 
>shortened, that needs to be used for the http.<url>.option setting.

This seems to be assuming that the configuration is done after the URL 
is entered and that URLs are always entered manually.  I don't think 
either of those assumptions is valid.  A user may want to specify http 
settings for all repositories on a specified host and so add settings 
for that host to ~/.gitconfig expecting those settings to be used later.  
A URL in a slightly different format may later be copy+pasted without 
the user realizing that it won't use that config due to one of the 
versions being in a non-canonical form.

>I think that's simple and very easy to explain and avoids user 
>confusion and surprise while still allowing a default to be set for a 
>site but easily overridden for a portion of that site without needing 
>to worry about the order config files are processed or the order of the 
>[http "<url>"] sections within them.

I agree that the method is easy to explain, but I think a user may very 
well be surprised and confused in a scenario like I described above.  
And having the order not matter (in some cases) for these configuration 
items deviates from how other configuration values are handled.