[PATCH] config: Rummage through ~/.gitrc as well as the repository's config.

[PATCH] config: Rummage through ~/.gitrc as well as the repository's config.

[Mark Wooding]

From: Mark Wooding <mdw@distorted.org.uk>

I'm fed up of setting user.email in every repository I own.  I want to
put this somewhere central, and I shouldn't have to log in again to make
it take effect.

Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---

 Documentation/git.txt |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/Documentation/git.txt b/Documentation/git.txt
index e8ef3ef..eab3d46 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -468,6 +468,10 @@ people.  Here is an example:
 Various commands read from the configuration file and adjust
 their operation accordingly.
 
+You can also have a global configuration file, in exactly the same
+format, in the file `.gitrc` in your home directory.  This is a handy
+place to put your name and email address.
+
 
 Identifier Terminology
 ----------------------

Re: [PATCH] config: Rummage through ~/.gitrc as well as the repository's config.

[Junio C Hamano]

Mark Wooding <mdw@distorted.org.uk> writes:

> I'm fed up of setting user.email in every repository I own.

That is what --template-dir to init-db is for (it works in an
already initialized git repository, but it does not overwrite
files).

> I want to put this somewhere central, and I shouldn't have to
> log in again to make it take effect.

I do not understand about logging in again.  If you are talking
about environment variables, ". ~/.env" would work nicely.

Re: [PATCH] config: Rummage through ~/.gitrc as well as the repository's config.

[Mark Wooding]

Junio C Hamano <junkio@cox.net> wrote:
> Mark Wooding <mdw@distorted.org.uk> writes:
>
>> I'm fed up of setting user.email in every repository I own.
>
> That is what --template-dir to init-db is for (it works in an
> already initialized git repository, but it does not overwrite
> files).

Except that git-clone has already made a .git/config file, so it won't
be overwritten by git-init-db --template-dir.  git-init-db doesn't do
merging of config file lines, and rightly so -- it'd just get too
confusing.

>> I want to put this somewhere central, and I shouldn't have to
>> log in again to make it take effect.
>
> I do not understand about logging in again.  If you are talking
> about environment variables, ". ~/.env" would work nicely.

Argh.  In every terminal and screen window, restart Emacs, ...  Logging
out looks like the better plan.

What's the objection to a ~/.gitrc?  (If it's just new-feature
resistance, I can live with that; I'm just interested.)

-- [mdw]

Re: [PATCH] config: Rummage through ~/.gitrc as well as the repository's config.

[Junio C Hamano]

Mark Wooding <mdw@distorted.org.uk> writes:

> Argh.  In every terminal and screen window, restart Emacs, ...  Logging
> out looks like the better plan.

So you do mean environment variables?  Then what's the aversion
against using GIT_AUTHOR_EMAIL instead of using user.email in
every repository?  If you use the same value everywhere, you
can do the environment thing _today_ and re-logging in needs to
be done only once, so I do not find it such a big deal.  If you
do _not_ use the same value everywhere, then user.email per
repository is a good thing to have, but ~/.gitrc would not help.

Having said that, there are good uses for per-user configuration
that is used across different repositories.  Especially when we
start adding new features, we would not want to invent new
environment variable every time.  Under ~/ would be a logical
place to put that information.

If you want to propose a search order of multiple configuration
files and how they interact with each other (what happens if
~/.gitrc and $GIT_DIR/config say different things, especially
for multi-valued configuration items), go wild.  I think the
simplest single-value cases should be resolved by taking what
$GIT_DIR/config says and if the configuration is not found there
then look at ~/.gitrc (IOW, $GIT_DIR/config takes precedence),
but I am not sure even if that is true in general.  I suspect
that some configuration items are more of personal nature and
some configuration items are more of per-project attribute.  For
example, merge resolve strategy would be affected more by the
nature of changes that happen to the project's files than which
strategy the user feels easier to work with; $GIT_DIR/config may
have core.gitproxy and user.email, maybe by historical reasons,
which you may rather want to override with ~/.gitrc (e.g. git
proxy may require proxy authentication which would need to be
supplied per user).

Especially problematic would be user.email.  Some people might
want to use different identity depending on what project they
work on, in which case they would want $GIT_DIR/config to take
precedence.  But sometimes you may need to go to your colleagues
repository and help him with his work, and when you make a
commit there you would want your name, not user.email in
$GIT_DIR/config that records his identity, to be used for that
commit.