From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Frédéric Brière" <fbriere@fbriere.net>, git@vger.kernel.org
Subject: Re: $GIT_CONFIG should either apply to all commands, or none at all
Date: Thu, 2 Oct 2014 11:59:19 -0400 [thread overview]
Message-ID: <20141002155919.GA2505@peff.net> (raw)
In-Reply-To: <20141002011546.GR1175@google.com>
On Wed, Oct 01, 2014 at 06:15:46PM -0700, Jonathan Nieder wrote:
> 3) Warn when 'git config' is called with GIT_CONFIG set, explaining
> that support will eventually be removed and that callers should
> pass --file= instead.
>
> 4) Once we're confident there are no scripts in the wild relying on
> that envvar, remove support for it.
I think you could do just these two without worrying about the
I_AM_PORCELAIN setting. It's completely redundant with `git config
--file` these days.
> Another possibility (B):
>
> 1) Teach git's commands in C to respect the GIT_CONFIG environment
> variable. Semantics: only configuration from that file would be
> respected and all other configuration will be ignored. Advertise
> it in the git(1) manpage.
I think this is a bad idea. It originally _did_ impact each command, but
there were a lot of confusing corner cases to the semantics, and it led
to bugs and misbehavior. That's what led to dc87183. I wish we had just
dropped it for git-config then, too. We kept it for backwards
compatibility, but we probably should have deprecated it more clearly.
> Yet another possibility (C):
>
> 1) Just skip to step (4) from plan (A).
I agree this is tempting. We have never deprecated it formally, but it
has been a little-used feature.
> C is kind of temping. Do you know if there are scripts in the wild
> that rely on the GIT_CONFIG setting working?
Searching here:
https://github.com/search?q=%22export+GIT_CONFIG%22&type=Code
reveals that some people do set it, but from the handful I investigated,
it is probably not doing what they want. For example, in:
https://github.com/GNOME/sysadmin-bin/blob/8ef4165a4b38fd1488c194f0c562c7fe24545bca/git/gnome-post-receive
they are trying to use it as if it affects all git commands, but as we
just discussed, it does not. So their script is potentially buggy as-is.
Getting rid of GIT_CONFIG would make it _more_ buggy, so perhaps that is
not an excuse, but I think it points to actually doing something.
-Peff
next prev parent reply other threads:[~2014-10-02 15:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20141002001034.24160.11848.reportbug@fabul.fbriere.net>
2014-10-02 1:15 ` $GIT_CONFIG should either apply to all commands, or none at all Jonathan Nieder
2014-10-02 15:59 ` Jeff King [this message]
2014-10-02 17:51 ` Junio C Hamano
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=20141002155919.GA2505@peff.net \
--to=peff@peff.net \
--cc=fbriere@fbriere.net \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.