Re: $GIT_CONFIG should either apply to all commands, or none at all

From: Jeff King <peff@peff.net>
Date: Oct 2, 2014, 15:59 UTC
Message-ID: <20141002155919.GA2505@peff.net>
In-Reply-To: <20141002011546.GR1175@google.com>

On Wed, Oct 01, 2014 at 06:15:46PM -0700, Jonathan Nieder wrote:

Show 6 quoted lines

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

Show 6 quoted lines

> 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