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

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

[Jonathan Nieder]

Hi,

Frédéric Brière wrote[1]:

> 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

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

[Jeff King]

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

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

[Junio C Hamano]

Jonathan Nieder <jrnieder@gmail.com> writes:

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