Another approach is [1]. I think this one is somewhat simpler and exposes less risk by putting the shared config under version control. This is not complete (for example, git-prune should learn about this), but is there any serious flaw that I missed? One thing that I haven't thought of is the shared config between subprojects. Maybe there's a better approach for subprojects. (The resistance to nd/struct-pathspec seems great. This is the second time I come to address it and end up with something else) [1] http://thread.gmane.org/gmane.comp.version-control.git/162309 Nguyán ThÃi Ngác Duy (3): config: read full file content before parsing config: add git_config_from_sha1() to read from a blob config: add core.sharedconfig cache.h | 1 + config.c | 110 +++++++++++++++++++++++++++++++++++++++++++-------------- environment.c | 1 + 3 files changed, 85 insertions(+), 27 deletions(-) -- 1.7.3.3.476.g893a9 -- 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