{"thread":{"id":"37662","subject":"Re: $GIT_CONFIG should either apply to all commands, or none at all","startedAt":"2014-10-02T01:15:46Z","lastAt":"2014-10-02T17:51:05Z","messageCount":3,"participants":["Jonathan Nieder","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"250133","messageId":"20141002011546.GR1175@google.com","threadId":"37662","inReplyTo":"20141002001034.24160.11848.reportbug@fabul.fbriere.net","subject":"Re: $GIT_CONFIG should either apply to all commands, or none at all","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-10-02T01:15:46Z","receivedAt":"2014-10-02T01:15:46Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nFrédéric Brière wrote[1]:\n\n> This kind of stuff caused me a lot of hair-pulling:\n>\n>   $ git config core.abbrev\n>   32\n>   git log --pretty=oneline --abbrev-commit\n>   89be foo\n>\n> Here's the source of the discrepancy:\n>\n>   $ grep abbrev $GIT_CONFIG .git/config\n>   git.conf:\tabbrev=32\n>   .git/config:\tabbrev=4\n>\n> Since dc87183, $GIT_CONFIG is ignored by any other Git command, but it\n> *still* applies to git-config.  This basically means that values\n> obtained via git-config are not necessarily those which are actually in\n> effect.\n>\n> The really frustrating part (for me, at least) is that for any tool\n> (gitweb in my case) which uses git-config, values from $GIT_CONFIG will\n> take effect for that tool, but not for any subsequent Git command.\n>\n> git-config(1) doesn't make this clear either; it mentions $GIT_CONFIG as\n> \"the configuration\", without saying explicitly that this environment\n> variable only applies to git-config.\n\nYep.  One possibility would be to do something like the following (A):\n\n 1) advertise in the git-config(1) manpage that the GIT_CONFIG\n    environment variable only affects the behavior of the 'git config'\n    command\n\n 2) introduce an environment variable GIT_I_AM_PORCELAIN.  (If doing\n    this, we could come up with a better name, but this is just an\n    illustration.)  Set and export that envvar in git-sh-setup.sh.\n    When that environment variable is set, make git-config stop paying\n    attention to GIT_CONFIG.\n\n    That way, git commands that happen to be scripts would not be\n    affected by the GIT_CONFIG setting any more.\n\n 3) Warn when 'git config' is called with GIT_CONFIG set, explaining\n    that support will eventually be removed and that callers should\n    pass --file= instead.\n\n 4) Once we're confident there are no scripts in the wild relying on\n    that envvar, remove support for it.\n\nAnother possibility (B):\n\n 1) Teach git's commands in C to respect the GIT_CONFIG environment\n    variable.  Semantics: only configuration from that file would be\n    respected and all other configuration will be ignored.  Advertise\n    it in the git(1) manpage.\n\n 2) Gnash teeth a little but continue to support it.\n\nYet another possibility (C):\n\n 1) Just skip to step (4) from plan (A).\n\nC is kind of temping.  Do you know if there are scripts in the wild\nthat rely on the GIT_CONFIG setting working?\n\nThanks for reporting,\nJonathan\n\n[1] http://bugs.debian.org/763712\n"},{"id":"250172","messageId":"20141002155919.GA2505@peff.net","threadId":"37662","inReplyTo":"20141002011546.GR1175@google.com","subject":"Re: $GIT_CONFIG should either apply to all commands, or none at all","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-10-02T15:59:19Z","receivedAt":"2014-10-02T15:59:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 01, 2014 at 06:15:46PM -0700, Jonathan Nieder wrote:\n\n>  3) Warn when 'git config' is called with GIT_CONFIG set, explaining\n>     that support will eventually be removed and that callers should\n>     pass --file= instead.\n> \n>  4) Once we're confident there are no scripts in the wild relying on\n>     that envvar, remove support for it.\n\nI think you could do just these two without worrying about the\nI_AM_PORCELAIN setting. It's completely redundant with `git config\n--file` these days.\n\n> Another possibility (B):\n> \n>  1) Teach git's commands in C to respect the GIT_CONFIG environment\n>     variable.  Semantics: only configuration from that file would be\n>     respected and all other configuration will be ignored.  Advertise\n>     it in the git(1) manpage.\n\nI think this is a bad idea. It originally _did_ impact each command, but\nthere were a lot of confusing corner cases to the semantics, and it led\nto bugs and misbehavior. That's what led to dc87183. I wish we had just\ndropped it for git-config then, too. We kept it for backwards\ncompatibility, but we probably should have deprecated it more clearly.\n\n> Yet another possibility (C):\n> \n>  1) Just skip to step (4) from plan (A).\n\nI agree this is tempting. We have never deprecated it formally, but it\nhas been a little-used feature.\n\n> C is kind of temping.  Do you know if there are scripts in the wild\n> that rely on the GIT_CONFIG setting working?\n\nSearching here:\n\n  https://github.com/search?q=%22export+GIT_CONFIG%22&type=Code\n\nreveals that some people do set it, but from the handful I investigated,\nit is probably not doing what they want. For example, in:\n\n  https://github.com/GNOME/sysadmin-bin/blob/8ef4165a4b38fd1488c194f0c562c7fe24545bca/git/gnome-post-receive\n\nthey are trying to use it as if it affects all git commands, but as we\njust discussed, it does not. So their script is potentially buggy as-is.\nGetting rid of GIT_CONFIG would make it _more_ buggy, so perhaps that is\nnot an excuse, but I think it points to actually doing something.\n\n-Peff\n"},{"id":"250177","messageId":"xmqqppeanywm.fsf@gitster.dls.corp.google.com","threadId":"37662","inReplyTo":"20141002011546.GR1175@google.com","subject":"Re: $GIT_CONFIG should either apply to all commands, or none at all","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-02T17:51:05Z","receivedAt":"2014-10-02T17:51:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> Yep.  One possibility would be to do something like the following (A):\n>\n>  1) advertise in the git-config(1) manpage that the GIT_CONFIG\n>     environment variable only affects the behavior of the 'git config'\n>     command\n>\n>  2) introduce an environment variable GIT_I_AM_PORCELAIN.  (If doing\n>     this, we could come up with a better name, but this is just an\n>     illustration.)  Set and export that envvar in git-sh-setup.sh.\n>     When that environment variable is set, make git-config stop paying\n>     attention to GIT_CONFIG.\n>\n>     That way, git commands that happen to be scripts would not be\n>     affected by the GIT_CONFIG setting any more.\n\nAt the places you plan to update porcelains to set and export\nGIT_I_AM_PORCELAIN, you could unset GIT_CONFIG if set.  Would that\nachieve the same goal?\n\nAnd you can stop there without doing 3 or 4, no?\n"}]}