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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
