git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] doc git: multivar configuration parameters append to existing values

From
Jeff King <peff@peff.net>
Date
Jun 16, 2014, 19:48 UTC
Message-ID
<20140616194849.GA24376@sigill.intra.peff.net>
In-Reply-To
<xmqqd2e8r8yz.fsf@gitster.dls.corp.google.com>
On Mon, Jun 16, 2014 at 11:43:32AM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> 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
Previous: Philip Oakley
Message 8 of 8 in “doc git: multivar configuration parameters append to existing values”
  1. doc git: multivar configuration parameters append to existing valuesPhilip Oakley, Jun 16, 2014
  2. Tanay AbhraJun 16, 2014
  3. Philip OakleyJun 16, 2014
  4. Junio C HamanoJun 16, 2014
  5. Philip OakleyJun 16, 2014
  6. Junio C HamanoJun 16, 2014
  7. Philip OakleyJun 17, 2014
  8. Jeff KingJun 16, 2014

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.