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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html