git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).