Is context/directory sensitive config possible or even a god idea?

Hello,

In some situations one person could be involved in various multi-repository projects and need to use different user.email information, depending on the project.

A simple example can be using the project specific email identity for all repositories part of Android, while using the personal email for personal projects on github.

The developer has currently only 2 options, AFAICT: a) use --global identity for the personal email and set the Android identity in all project repos b) use the reverse, store Android identity in --global gitconfig, and make sure to set the identity at repo level for personal projects.

Both solutions are suboptimal, especially if both the project in question has many repositories and the number github projects is high, because the user must remember to set the non-global user identity either in all github repos or in each Android repos, after checkout.

In my view, there should be a middle ground, having a context/directory dependent setting could be a solution.

My idea is somehting like "for all repos cloned in subdirs of directory ~/src/android, use identity johm.doe@android.org", so the only thing to remember to make this work is to make sure all android checkouts are done under ~/src/android, which most people already do because they need a clean home dir.

When I saw he include.path feature I thought this was exactly that, but when testing it did not work as I would have liked, the inluded config is simply added to the global config, if I add this to the ~/.gitconfig file and the target file exists.

I understand the use case I am thinking of is not the one that was addressed by the include.file feature, so I am thinking git would need some other setting like 'contextsensitive.include=/home/johndoe/src/android/.gitconfig' which could mean include the settings from this config is we're in a dir on the same level a the file, or a directory which has that dir as parent or ancestor.

What I see already:
1) it would be a perfomance hit if the test for "do we need to apply
any context sensitive setting" must be done on every git command; for
the identity usecase might be less of a problem if only the subcomands
that need user.* would compare the prefix of the current dir with all
all contextsensitive.inludes settings and applying only the longest
one
2) what if the contextsensitive.inluclude file also includes another
contextsensitive.include, could that lead to ambiguous situations?
3) having the feature could allow the user to set other project
specific settings. Nice usecases:
if Android uses --no-ff merge.ff=false in ~/src/andoid/.gitconfig
contextsensitive.inlclude would ensure the expected strategy is used,
and rebase is the preferred behaviour for pull, instead of merge)