Layered config

[epage]

For large projects, it can be helpful to support layered configs.

[epage]

I originally thought this was going to be a mess but I think #14 will take on most of that work.

Thoughts

• When depth==0, read search for parent configs until one is found in the config cache or the root is reached
  • "one found in cache" is to handle the user passing in multiple args
  • We might need to instead pre-populate the config before walking so we have the walk configuration
• When walking a directory, check if there is a config and add it to the config cache
• Cache stores config merged with parents but not merged with args, so we can merge it when loading a leaf
• Cache might also store config merged with args

[rgeronimi]

Layered configs are needed to support decentralized ignore files (see #867). Forcing ignored files to be declared in a central configuration file has 2 drawbacks:

• It assumes the configuration files is owned by the project - which is not the case in larger environments. We have 7 git projects, with various maintainers, and a separate project to centralize the tools and their configurations. In effect, most of the configuration needs are common and can be shared, only ignored files need to be customized by each project.
• It assumes, even within a single git project, that a centralized model to declare ignored files is better than decentralized. This is not necessarily the case in our experience, particularly for very large git projects. Having locally declared ignores allows to move directories, rename them, without having to duplicate all these changes in a centralized typos.toml configuration file once the linter raises the inconsistencies.

These 2 reasons are why git went down the decentralized .gitignore files model: it gives everybody the flexibility to decentralize, only when it's useful, a critical piece of the git configuration.