threads / patch / 3233

patchconfig: Rummage through ~/.gitrc as well as the repository's config.

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

## tl;dr

4 messages between Feb 3, 2006 and Feb 4, 2006. Diffs are folded; open one to read it.

replies: 3people: 2as markdown or json

Mark Wooding· Feb 3, 2006, 20:33 UTC · lore
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(-)
Show changes to Documentation/git.txt +4 −0
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
 ----------------------
Junio C Hamano· Feb 4, 2006, 01:15 UTC · re: Mark Wooding · lore

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

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.

Mark Wooding· Feb 4, 2006, 10:22 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <junkio@cox.net> wrote:
Show 7 quoted lines
> 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.

Show 5 quoted lines
>> 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]
Junio C Hamano· Feb 4, 2006, 12:17 UTC · re: Mark Wooding · lore

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

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.

← back to recent threads