From: Aaron Schrab Date: Fri, 12 Jul 2013 20:58:44 GMT Subject: Re: [PATCH v3] config: add support for http..* settings Message-ID: <20130712205843.GJ4604@pug.qqx.org> In-Reply-To: At 06:07 -0700 12 Jul 2013, "Kyle J. McKay" 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..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 ""] 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.