login
Search
I would like this, too. This would allow me to set e.g. "diff.color = auto" for everyone one a machine. We use git there to only manage some config files and several simple perl scripts. As it is mostly myself who does the editing, ~/.gitconfig works for *ME*. But I'd like to set this globally so that my colluagues which don't have much clue about git don't need to bother about config settings. And yes, editing every single repo doesn't seem like an elegant solution. -Peter -
The settings in /etc/gitconfig can be overridden in ~/.gitconfig, which in turn can be overridden in .git/config. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- On Wed, 14 Feb 2007, Peter Baumann wrote: > Andy Parkins <andyparkins@gmail.com> schrieb: > > > > With the release of 1.5.0 I added legacyheaders=false and > > usedelatbaseoffset=true to my repositories. > > > > While doing that though, it felt wrong to be editing every > > single config. Is there a justification for having three > > config files? > > > > /etc/gitconfig > > $HOME/.gitconfig > > $GIT_DIR/config > > > > With /etc/gitconfig coming in at lowest priority? > > I would like this, too. This would allow me to set e.g. > "diff.color = auto" for everyone one a machine. We use git there > to only manage some config files and several simple perl > scripts. As it is mostly myself who does the editing, > ~/.gitconfig works for *ME*. > > But I'd like to set this globally so that my colluagues which > don't have much clue about git don't need to bother about config > settings. And yes, editing every single repo doesn't seem like > an elegant solution. Voil
I knew this can be done, and you are capable of doing this, but I was wondering if it is a good thing to do in the first place. Site-wide configuration for options that are potentially compatibility-breaking is a bad idea on a multi-user machines, and it was certainly the case back when our machines hosted many diverse set of people. But these days many machines are practically single-user and many more are owned by a single group/project that share the same policy. So in such a setting, /etc/gitconfig might not be too bad. -
I am slightly worried about stupid distros screwing people over by shipping with a bad default config in /etc, which would make diagnosing their problems harder without knowing what they have there. But other than that I do not have a problem with it. -
Hi, They can do that already by shipping with a bad default /etc/skel/ directory. Ciao, Dscho -
That's slightly different. I can ask "Do you have anything special in your $HOME/.gitconfig?" Now I have to ask two questions (and I would not know if a particular distro compiled git to use /etc/git/default.config or /etc/gitconfig or whatever). -
Why not simplifying the question to only: git config -l then? Nicolas -
Isn't it more likely that on a multi-user machine all users are sharing one install of git - in which case you do want the upgrade of facilities to be system-wide. Otherwise you have to tell every user to edit their .gitconfig to enable the new facilities - users shouldn't have to care about that sort of thing, that's what admins are for. Andy -- Dr Andy Parkins, M Eng (hons), MIEE andyparkins@gmail.com -
Not really. Some repositories would need to be accessible by people with older git coming over the network. Some don't. -
this is a stupid idea. This should use the path given as the --sysconfdir argument to configure. If the configure result is not available, it should default to $prefix/etc/ It should be possible to install private copy of Git without being affected by system wide defaults. -- Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen -
Stupid probably is too strong a word, but I think I'd agree we should default it to $(prefix)/etc and have distros override it in the Makefile. -
Hi,
Fair enough. And my patch was not really complete. Please amend to spare
me eternal shame:
--
[BROWN PAPERBAG PATCH ON TOP OF OTHER PATCH]
It is $prefix/etc/gitconfig now, and works also if you do not
`git config -l`. D'oh.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 5 ++++-
builtin-config.c | 7 ++++++-
cache.h | 1 -
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 6f05abb..617908c 100644
--- a/Makefile
+++ b/Makefile
@@ -128,6 +128,7 @@ prefix = $(HOME)
bindir = $(prefix)/bin
gitexecdir = $(bindir)
template_dir = $(prefix)/share/git-core/templates/
+ETC_GITCONFIG = $(prefix)/etc/gitconfig
# DESTDIR=
# default configuration for gitweb
@@ -591,6 +592,7 @@ endif
# Shell quote (do not use $(call) to accommodate ancient setups);
SHA1_HEADER_SQ = $(subst ','\'',$(SHA1_HEADER))
+ETC_GITCONFIG_SQ = $(subst ','\'',$(ETC_GITCONFIG))
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
@@ -603,7 +605,8 @@ PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
LIBS = $(GITLIBS) $(EXTLIBS)
-BASIC_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' $(COMPAT_CFLAGS)
+BASIC_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' \
+ -DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"' $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
ALL_CFLAGS += $(BASIC_CFLAGS)
diff --git a/builtin-config.c b/builtin-config.c
index 0f9051d..34470c4 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -64,7 +64,7 @@ static int get_value(const char* key_, const char* regex_)
int ret = -1;
char *tl;
char *global = NULL, *repo_config = NULL;
- const char *local;
+ const char *system_wide = NULL, *local;
local = getenv(CONFIG_ENVIRONMENT);
if (!local) {
@@ -74,6 +74,7 @@ static int get_value(const char* key_, const char* regex_)
local = repo_config = xstrdup(git_path("config"));
if (home)
global = xstrdup(mkpath("%s/.gitconfig", ...How would we run our tests without getting screwed by whatever non-standard values system-wide configuration may have? Currently we disable tester's ~/.gitconfig by exporting HOME from t/test-lib.sh, but that will not work for this. I think we need to have a way to disable this setting, perhaps via an environment variable. I do not think we need to support 'git config --system --set foo.bar baz' but some people might have twisted minds ;-). -
Hi,
Yes. Just set GIT_CONFIG=/what/ever, and it no longer reads from
~/.gitconfig or $prefix/etc/gitconfig.
But this possibly breaks down when creating a repository in a subdirectory
;-) Yes, I'd rather not have an administrator run git directly. But it
_would_ be easy enough:
diff --git a/builtin-config.c b/builtin-config.c
index 0f9051d..a42d251 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -147,6 +152,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
} else {
die("$HOME not set");
}
+ else if (!strcmp(argv[1], "--system-wide")) {
+ setenv("GIT_CONFIG", ETC_GITCONFIG, 1);
} else if (!strcmp(argv[1], "--rename-section")) {
int ret;
if (argc != 4)
-
Hi, Ooops. There is a "}" missing before "else". Sorry, Dscho -
I think GIT_CONFIG and GIT_LOCAL_CONFIG environment variables are seriously misdesigned. At least, I do not think of a sane way to make use of them. For one thing, when they are set, truly per-repository variables such as repositoryformatversion, legacyheaders and sharedrepository are all ignored. What I would think is sensible would be simply to: - $GIT_CONFIG_SYSTEM environment, if set, names a file to be read first. It defaults to /etc/gitconfig. You can set it to /dev/null to avoid using /etc/gitconfig if you have specific need. - Then $HOME/.gitconfig is read. - Then $GIT_DIR/config is read. Information read from later files overrides the earlier ones, as before. I am not quite sure how $GIT_CONFIG and $GIT_CONFIG_LOCAL were meant to be used. Are there any *real* users? With lack of information on the intended uses of these two environment variables, I hacked up the following tweaks on top of the above defined semantics, to imitate what I _think_ was the original intention. The hacked one goes like this: - $GIT_CONFIG environment, if set, names a file to be read first. We read it first. - If $GIT_CONFIG is unset, then $GIT_CONFIG_SYSTEM (or /etc/gitconfig) and $HOME/.gitconfig are read, as above. - Next file to be read is $GIT_CONFIG_LOCAL (if set) or $GIT_DIR/config. When reading this file, if we read from $GIT_CONFIG earlier, we read only "core.*" section from it. The difference from the original, aside from the additional business with /etc/gitconfig, is that this updated one does read from $GIT_DIR/config (or $GIT_CONFIG_LOCAL) to avoid missing more important per-repo variables. Since I did not understand why $GIT_CONFIG makes the remaining configuration files to be totally skipped in the original, I added hacks to make the last step to read only minimally. I'd rather not to have the hacks to deal with GIT_CONFIG and GIT_CONFIG_LOCAL I did in this patch, but I do not know enough to tell if they are ...
Addendum. Judging from the way builtin-config.c::get_value() uses it, I think whoever invented $GIT_CONFIG_LOCAL as a parallel to $GIT_INDEX_FILE and $GIT_OBJECT_DIRECTORY, in other words, what usually appear under $GIT_DIR can be placed somewhere completely different. So I think the above "hack" I described still honors its intended use. I am still not sure what good GIT_CONFIG would be to completely override everything else, though. -
I just started using GIT_CONFIG in the experimental version of git-svn[1] which allows me to use .git/svn/config for tracking some metadata bits. I didn't want to pollute the users' .git/config with automatically read and state data in .git/config; so I started using .git/svn/config to avoid littering .git/svn/ with any tiny pieces of data I might need. -- Eric Wong [1] - git://bogomips.org/git-svn -
GIT_CONFIG continues to work here with the latest git-svn + your hack -- Eric Wong -
Hi,
Okay for GIT_LOCAL_CONFIG. I do not remember off-hand who wanted it
(Jakub? Pasky?), but it was in the context of gitweb.
However, GIT_CONFIG is meant to parse arbitrary config files. You can
literally say
GIT_CONFIG=/windows/C/WINNT/system.ini git config drivers.wave
and get the value for "wave" in system.ini, section [drivers].
BTW I find the HOME mangling in test-lib.sh insane. Here's a replacement:
-- snip --
[PATCH] Make tests independent of global config files
This was done by setting $HOME to somewhere bogus. A better method is
to reuse $GIT_CONFIG, which was invented for ignoring the global
config file explicitely.
Technically, setting GIT_CONFIG=.git/config could be wrong, but it
passes all the tests, and we can keep the tests that way.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/test-lib.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 37822fc..a403fe0 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -255,8 +255,8 @@ test_done () {
PATH=$(pwd)/..:$PATH
GIT_EXEC_PATH=$(pwd)/..
GIT_TEMPLATE_DIR=$(pwd)/../templates/blt
-HOME=$(pwd)/trash
-export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR HOME
+GIT_CONFIG=.git/config
+export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG
GITPERLLIB=$(pwd)/../perl/blib/lib:$(pwd)/../perl/blib/arch/auto/Git
export GITPERLLIB
Yes, you can. But I'd rather not. The contents of /etc/gitconfig should be
changed with care, and _if_ they are changed, you should be forced to
override the settings explicitely in $HOME/.gitconfig.
As I said, I _think_ it was the gitweb people, who wanted to have this to
I am all for removing support for $GIT_CONFIG_LOCAL. IMHO it really does
not make sense, for the reasons you told in your email: important per-repo
information would be ignored, but not global or system-wide settings.
GIT_CONFIG should be used when reading a config which is totally unrelated
to a ...Ok, Eric's example and yours made it clear that GIT_CONFIG is an interface meant to reuse (or abuse) git-config to read some file that is not at all related to git, and should never be used by other plumbing. As long as that is clear (could we have that in the documentation, by the way, please?), I have no problem with that. In fact, I am very happy that we do not have to do that insane "core.*" stuff, which I thought was needed purely because somebody was trying to use GIT_CONFIG to prevent plumbing and porcelain from reading core configuration variables that are per repository in nature. As I said in my other message, GIT_LOCAL_CONFIG is parallel to GIT_OBJECT_DIRECTORY and GIT_INDEX_FILE, and I am Ok with the way it is handled by the current code. I mildly disagree with you on having an ability to disable /etc/gitconfig. This is necessary in the real world (in the same sense as "adduser" can be told not to copy skeltons by creating an empty home directory beforehand), even if we do not consider the fact that it would help gaining repeatable results from our test scripts (remember, using GIT_CONFIG to make plumbing and porcelain read from there would set a bad example, even when it is pointing at .git/config). I've queued that insane "core.*" stuff in 'pu' and pushed out, but I'll drop that topic altogether. But before doing that, it's past my bedtime ;-). -
Hi, I am no particularly good with documentation, but the good people who I'm okay either way. But I thought /etc/gitconfig was not so much like Hey, take it easy, now that Git "snog" is out! Ciao, Dscho -
