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

[Jonathan Nieder <jrnieder@gmail.com>]

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