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.