threads / discuss / 37662

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

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

## tl;dr

3 messages between Oct 2, 2014 and Oct 2, 2014.

replies: 2people: 3as markdown or json

Jonathan Nieder· Oct 2, 2014, 01:15 UTC · lore
Hi,
Frédéric Brière wrote[1]:
Show 25 quoted lines
> This kind of stuff caused me a lot of hair-pulling:
>
>   $ git config core.abbrev
>   32
>   git log --pretty=oneline --abbrev-commit
>   89be foo
>
> Here's the source of the discrepancy:
>
>   $ grep abbrev $GIT_CONFIG .git/config
>   git.conf:	abbrev=32
>   .git/config:	abbrev=4
>
> Since dc87183, $GIT_CONFIG is ignored by any other Git command, but it
> *still* applies to git-config.  This basically means that values
> obtained via git-config are not necessarily those which are actually in
> effect.
>
> The really frustrating part (for me, at least) is that for any tool
> (gitweb in my case) which uses git-config, values from $GIT_CONFIG will
> take effect for that tool, but not for any subsequent Git command.
>
> git-config(1) doesn't make this clear either; it mentions $GIT_CONFIG as
> "the configuration", without saying explicitly that this environment
> variable only applies to git-config.
Yep.  One possibility would be to do something like the following (A):
 1) advertise in the git-config(1) manpage that the GIT_CONFIG
    environment variable only affects the behavior of the 'git config'
    command
 2) introduce an environment variable GIT_I_AM_PORCELAIN.  (If doing
    this, we could come up with a better name, but this is just an
    illustration.)  Set and export that envvar in git-sh-setup.sh.
    When that environment variable is set, make git-config stop paying
    attention to GIT_CONFIG.
    That way, git commands that happen to be scripts would not be
    affected by the GIT_CONFIG setting any more.
 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.
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.
 2) Gnash teeth a little but continue to support it.
Yet another possibility (C):
 1) Just skip to step (4) from plan (A).

C is kind of temping. Do you know if there are scripts in the wild that rely on the GIT_CONFIG setting working?

Thanks for reporting, Jonathan

[1] http://bugs.debian.org/763712
Jeff King· Oct 2, 2014, 15:59 UTC · re: Jonathan Nieder · lore
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
Junio C Hamano· Oct 2, 2014, 17:51 UTC · re: Jonathan Nieder · lore
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 14 quoted lines
> Yep.  One possibility would be to do something like the following (A):
>
>  1) advertise in the git-config(1) manpage that the GIT_CONFIG
>     environment variable only affects the behavior of the 'git config'
>     command
>
>  2) introduce an environment variable GIT_I_AM_PORCELAIN.  (If doing
>     this, we could come up with a better name, but this is just an
>     illustration.)  Set and export that envvar in git-sh-setup.sh.
>     When that environment variable is set, make git-config stop paying
>     attention to GIT_CONFIG.
>
>     That way, git commands that happen to be scripts would not be
>     affected by the GIT_CONFIG setting any more.

At the places you plan to update porcelains to set and export GIT_I_AM_PORCELAIN, you could unset GIT_CONFIG if set. Would that achieve the same goal?

And you can stop there without doing 3 or 4, no?

← back to recent threads