On Tue, Feb 28, 2017 at 12:08 PM, Jeff King <peff@xxxxxxxx> wrote: > On Tue, Feb 28, 2017 at 10:05:24AM -0800, Stefan Beller wrote: > >> > I have a feeling that something like this would create unwelcome corner >> > cases in the config-writer, which is otherwise does not have to care >> > about which existing section of a file it adds a key to. >> >> Yeah the writer would become a lot more involved, if we're not going >> the stupid way (add these sections for nearly all keys. that would be >> a mess but easy to implement) >> >> So I guess then we rather settle with multiple config files or a white/blacklist >> of config options to propagate from the superproject to its submodules. > > I'm still open to the idea that we simply improve the documentation to > make it clear that per-repo config really is per-repo, and is not shared > between super-projects and submodules. And then something like Duy's > proposed conditional config lets you set global config that flexibly > covers a set of repos. How would the workflow for that look like? My naive thought on that is: (1) $EDIT .git/config_to_be_included (2) $ git config add-config-inclusion .git/config_to_be_included (3) $ git submodule foreach git config add-inclusion-config .git/config_to_be_included which sounds a bit cumbersome to me. So I guess we'd want some parts of that as part of another command, e.g. (3) could be part of (2). -- I am also open and willing to document this better; but were would we want to put documentation? Obviously we would not want to put it alongside each potentially useful config option to be inherited to submodules. (that would imply repeating ourselves quite a lot in the config man page). I guess putting it into "man gitmodules" that I was writing tentatively would make sense. C.f https://public-inbox.org/git/20161227234310.13264-4-sbeller@xxxxxxxxxx/ (or search for "background story" in your emails) Thanks, Stefan