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