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

config-file includes

From
Jeff King <peff@peff.net>
Date
Sep 23, 2011, 19:58 UTC
Message-ID
<20110923195829.GA27677@sigill.intra.peff.net>
On Fri, Sep 23, 2011 at 03:33:41PM -0400, Jeff King wrote:
Show 9 quoted lines
> [1] I really wish we had an elegant way of versioning meta-information
>     about a repository (like config, info/attributes, etc). I've hacked
>     around this before by having a special meta-branch for each repo,
>     checkout it out in an alternate directory, and then symlinking bits
>     of it into .git. But that's kind of ugly, too.
> 
>     I'm not sure what a good solution would look like. There's a real
>     can of worms with respect to picking and choosing local versus
>     remote bits of meta-information, with some security implications.
Here's one solution I've given a little thought to. Comments welcome.

I've sometimes wanted an "include" mechanism in git config files. Partially to just keep things tidier, partially to avoid cutting-and-pasting between some repo-specific config, and partially because I'd like a conditional inclusion mechanism[1]. I was thinking of something that would be syntactically compatible but semantically meaningless in current versions of git, like:

  [include]
  path = /some/file
  path = /some/other/file
  path = ~/some/file/in/your/homedir
You could extend this to look in refs, with something like:
  [include]
  ref = meta:config

which would resolve meta:config to a blob and examine it (i.e., it would look at refs/heads/meta).

So the procedure for importing and updating config from a remote would look like:

  git clone project.git
  cd project
  # check that the upstream config looks good
  git show origin/meta:config
  # if so, use it
  git branch meta origin/meta
  git config --add include.ref meta:config
  # later, check updates to upstream's config
  git fetch
  git diff meta origin/meta -- config
  # looks ok, use it
  git branch -f meta origin/meta

And obviously if you wanted to streamline that, you could make "meta" and "config" well-known names and have clone and fetch interactively show the config and say "do you want this [y/N]?" or something. Though I think there is some value to doing it manually, as it gives projects the flexibility to have different config profiles in their meta branch.

And if you really wanted to live dangerously, you could do:
  git config --add include.ref origin/meta:config

That of course just covers "config". But I think you might be able to do something similar with core.attributesfile (which could be included from the config).

-Peff
[1] I want conditional inclusion because sometimes the rules for config
    entries changes from version to version. For example, I have
    pager.diff set to a script in my ~/.gitconfig. But older versions of
    git don't understand non-boolean values and barf. I'd really like to
    do something like:
    [include-ifdef "has-pager-scripts"]
    path = ~/.gitconfig-pager
    where "has-pager-scripts" would be a magic flag compiled into git
    versions that understand that config.
Next: Nguyen Thai Ngoc Duy
Message 1 of 8 in “config-file includes”
  1. Jeff KingSep 23, 2011
  2. Nguyen Thai Ngoc DuySep 26, 2011
  3. Jeff KingSep 26, 2011
  4. David AguilarSep 26, 2011
  5. Jeff KingSep 26, 2011
  6. Junio C HamanoSep 26, 2011
  7. Jay SoffianSep 27, 2011
  8. Jeff KingSep 27, 2011

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.