On Sat, Sep 24, 2011 at 5:58 AM, Jeff King <peff@xxxxxxxx> wrote: > 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). I had something similar [1], although I disregarded worktree content completely. One thing about this meta thing is fsck/prune must dig in config file in order not to accidentally remove something config file refers to. Another thing is, what if I want to exclude certain part of the included config? [1] http://thread.gmane.org/gmane.comp.version-control.git/163285/focus=163288 > [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. But how far would you go with conditional expressions? -- Duy -- 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