On Mon, Jun 16, 2014 at 11:43:32AM -0700, Junio C Hamano wrote:
> I have two doubts, while appreciating the overall direction to
> clarify things very much.
> * "single overrides, multiple appends" is not a wrong explanation
> per-se, but sounds like an arbitrary rule that forces people to
> memorize. I wonder if it makes it less burdensome for readers if
> we just said "Git acts as if the given configuration is specified
> at the very end of the configuration files"---once the reader
> understands that Git reads all configuration varilables of the
> same name and the code paths that *use* one of them pick the one
> defined the last, it is easy to realize that "single overrides"
> is merely a natural consequence of the appending nature of "-c".
Yeah, I think the problem is really not one of "-c" in particular. If
git config --system remote.magic.url some-default
to provide a universal alias for the "magic" remote, you could not
override it via ~/.gitconfig or .git/config, for the same reasons.
I think we need a better discussion of multivar versus "normal"
overridable variables in config.txt, and then "-c" can make a note that
this is a potential issue, and refer readers to the right section.
I also think it would be nice to have a syntax to "reset" multivars to
their initial state (both from config files and from "-c"). Their
inability to be overridden is one of the reasons we have so few of them.
> * The last sentence added, i.e. "insteadof"-style, will not be
> understood by any reader other than those who tried to use "-c"
> on remote.*.url variables and does not belong here. A better
> way/place to give that information is needed.
Agreed. I think that could go in the discussion I mentioned above (as
"some variables have other mechanisms to accomplish the same thing,
like..."). But if we learned a mechanism for resetting multivars, such
workarounds would not be needed at all.
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