All of lore.kernel.org
 help / color / mirror / Atom feed
* Is context/directory sensitive config possible or even a god idea?
@ 2018-03-09 22:33 Eddy Petrișor
  2018-03-09 22:57 ` Junio C Hamano
  0 siblings, 1 reply; 2+ messages in thread
From: Eddy Petrișor @ 2018-03-09 22:33 UTC (permalink / raw)
  To: git

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Is context/directory sensitive config possible or even a god idea?
  2018-03-09 22:33 Is context/directory sensitive config possible or even a god idea? Eddy Petrișor
@ 2018-03-09 22:57 ` Junio C Hamano
  0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2018-03-09 22:57 UTC (permalink / raw)
  To: Eddy Petrișor; +Cc: git

Eddy Petrișor <eddy.petrisor@gmail.com> writes:

> When I saw he include.path feature ...

Do you mean includeIf.<condition>.path?

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2018-03-09 22:58 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-09 22:33 Is context/directory sensitive config possible or even a god idea? Eddy Petrișor
2018-03-09 22:57 ` Junio C Hamano

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.