Re: [RFC PATCH v2 4/4] config: add 'config.superproject' file

> Some configs, such as wrapper directives like gerrit.createChangeId, or
> forthcoming hook configs, should apply to a superproject as well as all
> its submodules. It may not be appropriate to apply them globally - for
> example, if the user also contributes to many projects which do not use
> the configs necessary for one project-with-submodules - and it may be
> burdensome to apply them locally to the superproject and each of its
> submodules. Even if the user runs 'git submodule foreach "git config
> --local foo.bar', if a new submodule is added later on, that config is
> not applied to the new submodule.
>
> It is also inappropriate to share the entire superproject config, since
> some items - like remote URLs or partial-clone filters - would not apply
> to a submodule.
>
> To make life easier for projects with many submodules, then, create a
> new "config.superproject" config scope, which is included in the config
> parse for the superproject as well as for all the submodules of that
> superproject.
>
> For the superproject, this new config file is equally local to the local
> config; for the submodule, the new config file is less local than the
> local config. So let's include it directly before the local config
> during the config parse.
>
> Signed-off-by: Emily Shaffer <emilyshaffer@google.com>
> ---
>
> Notes:
>     Since v1:
>
>     - Used test_when_finished liberally in tests instead of bare cleanup steps
>     - Fixed some nits regarding xstrdup instead of strbuf_detach.
>
>     One thing that I thought about but did not implement: rather than finding the
>     path to the superproject's gitdir, you could imagine gathering the config by
>     making a call out to 'git -C ../ config' - but on second thought, it seems like
>     that will make it harder to edit. However, if we don't want to be able to edit
>     superproject config from a submodule, that might be okay... (This approach could
>     make 'git config --show-origin' harder to implement, though, I think.) So I did
>     not make any changes about that.