At 06:07 -0700 12 Jul 2013, "Kyle J. McKay" <mackyle@xxxxxxxxx> 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.
-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html