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

From: Aaron Schrab <aaron@schrab.com>
Date: Jul 12, 2013, 20:58 UTC
Message-ID: <20130712205843.GJ4604@pug.qqx.org>
In-Reply-To: <F5272E14-188E-4199-9523-D2ED66574D91@gmail.com>

At 06:07 -0700 12 Jul 2013, "Kyle J. McKay" <mackyle@gmail.com> wrote:

Show 5 quoted lines

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

Show 5 quoted lines

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