config-file includes

[Jeff King <peff@peff.net>]

On Fri, Sep 23, 2011 at 03:33:41PM -0400, Jeff King wrote:

> [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.