Am 26.01.2012 23:51, schrieb Jeff King: > However, I didn't think about the fact that git-submodule.sh would be > calling git-config separately, and that is accidentally changed by my > patch. Even if we changed git-submodule to use "git config > --no-includes" that would break any third-party scripts that use "git > config" to read git-like files. > > But it would be nice for callers doing "git config foo.bar" to get the > includes by default. So maybe the right rule is: > > 1. In C: > a. git_config() respects includes automatically. > b. other callers do not do so automatically (e.g., gitmodules via > submodule.c). > > (i.e., what is implemented by this patch) > > 2. Callers of git-config: > a. respect includes for lookup that checks all of the "normal" > config spots in sequence: .git/config, ~/.gitconfig, and > /etc/gitconfig. These are the shell equivalent of calling > git_config(). > > b. when we are looking in a specific file (via GIT_CONFIG or "git > config -f"), do not respect includes (but allow --includes if > the caller chooses). This specific file may be something like > .gitmodules. Or perhaps somebody is saying "no, I really just > want to know what is in _this_ file, not what the config > ecosystem tells me in general". > > And then because of 1a and 2a, most programs should Just Work without > any changes, but because of 1b and 2b, any special uses will have to > decide manually whether they would want to allow includes. > > Does that make sense? To me it really does. It lets submodule.c:gitmodules_config and "git config -f .gitmodules" behave in the same way, which is very important for consistent behavior between the submodule script and the submodule functionality that is already handled in c. And I don't know of a use case for includes in .gitmodules (the main reason for adding includes seems to be to enable users to have configuration stored in the repo, which the .gitmodules file already is. And if it is about having out of repo configuration blended in, .gitmodules settings are always overridden by those in .git/config, and you can use includes there). The only thing I'm not so sure about is the GIT_CONFIG case. I don't know if using this is rather a "I moved my config there, but please respect includes there too" or a "I want git config to look at a completely different file" use case. Probably both. But also the question of where to look for relative paths seems not so easy to answer for the GIT_CONFIG case, so it might be best to just disable includes there too. -- 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