Jeff King <peff@xxxxxxxx> writes: > So fundamentally, includes make the idea of "overwrite this value" much > more complex. I do not think it is anything new that include.path brings. To give the user a complete view of "what customization applies when working in this repository?", and to allow the user to edit variables in the right file among usual three places, the tool already needs to be aware of possible places and give users a way to tell where the edit needs to go anyway. include.path only adds one more thing for the tool to be aware of. With your example, the editor can show git config -f .git/config --list with "include.path=~/.gitident" listed as one of the key=value pairs without showing key=value pairs included from that file. Or it can show user.name in effect is this value from .git/config, and optionally also show that there are other definitions of user.name in ~/.gitconfig (which we use as if we have "include.path=~/.gitconfig" at the top of .git/config file) or ~/.gitident specified with include.path. The tool needs to make it easy to jump to ~/.gitident; it needs to know what include.path means. The user can edit the value in ~/.gitident, or after looking at ~/.gitident, choose to come back to .git/config and add an overriding entry there. > But isn't "git cola" a git-config editing program? Yes, that is really the right "rhetorical" question to ask. It needs to know what it is editing, so it at least needs to be _aware_ of the inclusion, where each item comes from, and how to edit contents of _one_ particular file. And that issue is not something new that was introduced by include.path. -- 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