From: Jakub Narebski <jnareb@gmail.com>
To: git@vger.kernel.org
Subject: Re: [PATCH] config: read system-wide defaults from /etc/gitconfig
Date: Mon, 19 Feb 2007 02:47:00 +0100 [thread overview]
Message-ID: <eravet$noq$1@sea.gmane.org> (raw)
In-Reply-To: 7vvei3d5n5.fsf@assigned-by-dhcp.cox.net
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> 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.
>> ...
>> But this "core.*" stuff is insane. Please no.
>
> 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).
Hmmm... documentation of GIT_CONFIG and GIT_LOCAL_CONFIG is a bit
behind, I guess:
git-repo-config(1):
ENVIRONMENT
GIT_CONFIG
Take the configuration from the given file instead of .git/config.
Using the "--global" option forces this to ~/.gitconfig.
GIT_CONFIG_LOCAL
Currently the same as $GIT_CONFIG; when Git will support global con-
figuration files, this will cause it to take the configuration from
the global configuration file in addition to the given file.
In my opionoin the logic should be: first read /etc/gitconfig, or
GIT_SYSTEM_CONFIG, if it exists, then ~/.gitconfig, if it exists, then
$GIT_DIR/config or GIT_LOCAL_CONFIG; if GIT_CONFIG is set, read only this.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
next prev parent reply other threads:[~2007-02-19 1:45 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-14 9:09 /etc/gitconfig Andy Parkins
2007-02-14 10:30 ` /etc/gitconfig Peter Baumann
2007-02-14 11:48 ` [PATCH] config: read system-wide defaults from /etc/gitconfig Johannes Schindelin
2007-02-14 16:30 ` Junio C Hamano
2007-02-14 17:45 ` Johannes Schindelin
2007-02-14 17:57 ` Junio C Hamano
2007-02-14 18:02 ` Johannes Schindelin
2007-02-14 18:12 ` Junio C Hamano
2007-02-14 18:19 ` Nicolas Pitre
2007-02-14 19:06 ` Junio C Hamano
2007-02-15 10:19 ` Andy Parkins
2007-02-15 11:26 ` Junio C Hamano
[not found] ` <20070215113557.GB2282@steel.home>
[not found] ` <20070216143952.GA2478@steel.home>
2007-02-16 14:42 ` [PATCH] Allow config files to be included Alex Riesen
2007-02-16 14:45 ` Alex Riesen
2007-02-14 18:10 ` [PATCH] config: read system-wide defaults from /etc/gitconfig Han-Wen Nienhuys
2007-02-14 19:07 ` Junio C Hamano
2007-02-14 19:25 ` Johannes Schindelin
2007-02-14 19:43 ` Junio C Hamano
2007-02-14 19:54 ` Johannes Schindelin
2007-02-14 22:39 ` Johannes Schindelin
2007-02-15 5:27 ` Junio C Hamano
2007-02-15 8:46 ` Junio C Hamano
2007-02-15 9:59 ` Eric Wong
2007-02-15 10:03 ` Eric Wong
2007-02-15 10:36 ` Junio C Hamano
2007-02-15 10:43 ` Johannes Schindelin
2007-02-15 11:25 ` Junio C Hamano
2007-02-15 12:05 ` Johannes Schindelin
2007-02-19 1:47 ` Jakub Narebski [this message]
2007-02-14 10:40 ` /etc/gitconfig Uwe Kleine-König
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='eravet$noq$1@sea.gmane.org' \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).