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

["Eddy Petrișor" <eddy.petrisor@gmail.com>]

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)


-- 
Eddy Petrișor