Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: > Am 1/27/2012 6:42, schrieb Jeff King: >> That being said, I think it would be nicer for projects to carry meta >> information like this out-of-tree in a special ref. It's just simpler to >> work with, and it means the project's source isn't polluted with extra >> junk. > > Really? I doubt that carrying configuration in a special ref outside the > normal contents will have any practical relevance: > > To manage such a config file would mean to switch to a branch with > entirely different contents. But before you can test the new configuration > in action, you have to commit, switch branches, which exchanges the > worktree completely; and if the config change didn't work out, repeat the > process (and if we are talking about source code repository, this usally > includes a complete rebuild). Sure, you could keep the config branch in a > separate repository, but, again, how do you test an updated configuration? > It is not funny, and nobody will go this route. > > Which raises doubts about the usefulness of the include.ref feature. Hmm, good point. What I envisioned, when I said "meta:gitconfig" might make sense, was to do something like: * have a separate worktree via git-new-worktree in meta/, so that you do not have to switch away from the "source" branch and trash the working tree for it; and * update meta/gitconfig, perhaps make commit there, and possibly push it back for public consuption. In other words, I think "you *could* keep the config branch in a separate repository" is more like "you would most likely want to have a separate checkout of the config branch for this 'meta' branch to be useful". And at that point, as you said, setting include.path = meta/gitconfig (with possibly adding meta/ in .git/info/exclude) would be far more pleasant, because you would have a chance to experiment your changes to the file before committing it. So having include.ref, while it is a fun thought experiment, would not help very much in the real life. -- 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