From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Philip Oakley" <philipoakley@iee.org>,
GitList <git@vger.kernel.org>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Robert Clausecker" <fuz@fuz.su>,
"Alex Riesen" <raa.lkml@gmail.com>,
"Tanay Abhra" <tanayabh@gmail.com>
Subject: Re: [PATCH] doc git: multivar configuration parameters append to existing values
Date: Mon, 16 Jun 2014 15:48:49 -0400 [thread overview]
Message-ID: <20140616194849.GA24376@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqd2e8r8yz.fsf@gitster.dls.corp.google.com>
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
you did:
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.
-Peff
prev parent reply other threads:[~2014-06-16 19:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 12:49 [PATCH] doc git: multivar configuration parameters append to existing values Philip Oakley
2014-06-16 18:35 ` Tanay Abhra
2014-06-16 19:42 ` Philip Oakley
2014-06-16 18:43 ` Junio C Hamano
2014-06-16 19:38 ` Philip Oakley
2014-06-16 21:10 ` Junio C Hamano
2014-06-17 22:03 ` Philip Oakley
2014-06-16 19:48 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140616194849.GA24376@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=fuz@fuz.su \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=philipoakley@iee.org \
--cc=raa.lkml@gmail.com \
--cc=tanayabh@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).