Re: $GIT_CONFIG should either apply to all commands, or none at all
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%22type=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 -- 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
Re: $GIT_CONFIG should either apply to all commands, or none at all
Jonathan Nieder jrnie...@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? -- 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
Re: $GIT_CONFIG should either apply to all commands, or none at all
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
