On Fri, May 12, 2017 at 10:34 PM, Jeff King <p...@peff.net> wrote:
> On Fri, May 12, 2017 at 10:19:59AM -0400, Josh Hagins wrote:
>
>> Since upgrading to Git 2.13.0 I'm seeing this error message whenever
>> `git config --local <whatever>` is called outside a Git repository.
>> For example, note the difference in behavior between Git 2.13 and
>> Apple Git:
>>
>> $ pwd
>> /Users/jhagins
>> $ /usr/bin/git --version
>> git version 2.11.0 (Apple Git-81)
>> $ /usr/bin/git config --local --get user.name
>> $ /usr/local/bin/git --version
>> git version 2.13.0
>> $ /usr/local/bin/git config --local --get user.name
>> fatal: BUG: setup_git_env called without repository
>>
>> Apple Git outputs nothing, as expected. The summarized release notes
>> published by GitHub specifically mentioned that instances of this
>> error message should be reported, so here you go!
>
> Thanks for reporting. All the developers have been running with this
> change for months, but I knew as soon as it was released into the wild
> that somebody would find a new corner case. :)
>
> I think dying is the right thing here; you are asking for "--local" but
> there is no local repository. But we should never hit a BUG assertion.
> Patch is below.
>
> I'm not sure exactly what you wanted to accomplish with --local. If you
> just want to know if user.name is set anywhere (and you may or may not
> be in a git repo), then just "git config --get user.name" would work. If
> you want to know if you're in a local repo and if so whether the
> variable is set, you'd need to use two commands, like:
>
> git rev-parse --git-dir >/dev/null 2>&1 &&
> git config --local --get user.name
>
> -- >8 --
> Subject: [PATCH] config: complain about --local outside of a git repo
>
> The "--local" option instructs git-config to read or modify
> the repository-level config. This doesn't make any sense if
> you're not actually in a repository.
>
> Older versions of Git would blindly try to read or write
> ".git/config". For reading, this would result in a quiet
> failure, since there was no config to read (and thus no
> matching config value). Writing would generally fail
> noisily, since ".git" was unlikely to exist. But since
> b1ef400ee (setup_git_env: avoid blind fall-back to ".git",
> 2016-10-20), we catch this in the call to git_pathdup() and
> die("BUG").
>
> Dying is the right thing to do, but we should catch the
> problem early and give a more human-friendly error message.
>
> Note that even without --local, git-config will sometimes
> default to using local repository config. These cases are
> already protected by a similar check.
>
> Signed-off-by: Jeff King <p...@peff.net>
> ---
> builtin/config.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/builtin/config.c b/builtin/config.c
> index 3a554ad50..ad7c6a19c 100644
> --- a/builtin/config.c
> +++ b/builtin/config.c
> @@ -496,6 +496,9 @@ int cmd_config(int argc, const char **argv, const char
> *prefix)
> usage_with_options(builtin_config_usage,
> builtin_config_options);
> }
>
> + if (use_local_config && nongit)
> + die(_("--local only be used inside a git repository"));
> +
> if (given_config_source.file &&
> !strcmp(given_config_source.file, "-")) {
> given_config_source.file = NULL;
> --
> 2.13.0.452.g0afc8e12b
It would be better to have a test for edge cases that are currently
only being discovered by users in the wild.
