My feeling about this is that .coveragerc details are important to share with other collaborators on a project. This means that the config file should be part of the repo. Finding a config file in the users home directory makes it easy for people working together on a project to use different settings, which is not great.
Or have I missed a use case here?
If you want to have a config file in your home directory to share among your own private projects, you can do that with a command-line setting.
Maybe I should add a COVERAGE_CONFIG environment variable so you can set this once.
cat ~/.coveragerc # global, usefull to share with pastebin/gists/etc
cat /path/to/repo/.coveragerc # local
*appscript* # include appscript coverage in this repo
# *aem* already excluded
# * AppKit* already excluded
cat /path/to/repo_with_collaborators/.coveragerc # local
*aem* # defined here to make it visible to all collaborators
*AppKit* # defined here to make it visible to all collaborators
*appscript* # defined here to make it visible to all collaborators
As I understand it, you want them chained so that your middle case (/path/to/repo) wouldn't need to repeat aem and AppKit in the .coveragerc file, is that right?
I'm not convinced this is a good idea. The settings you are showing in the ~/.coveragerc file are settings that you want in all your projects. You should put them in your projects. The difference between a .coveragerc file and a .gitconfig file is that some git settings really do only apply to the current user (such as colors, or email address). But all of the settings in a .coveragerc file are about the project, not the user, and so they should all go in the project tree, in a .coveragerc file.