On Wed, Jul 31, 2019 at 01:06:42PM -0700, Johannes Schindelin via GitGitGadget wrote:
> Since 07b2c0eacac (config: learn the "onbranch:" includeIf condition,
> 2019-06-05), there is a potential catch-22 in the early config path: if
> the `include.onbranch:` feature is used, Git assumes that the Git
> directory has been initialized already. However, in the early config
> code path that is not true.
>
> One way to trigger this is to call the following commands in any
> repository:
>
> git config includeif.onbranch:refs/heads/master.path broken
> git help -a
>
> The symptom triggered by the `git help -a` invocation reads like this:
>
> BUG: refs.c:1851: attempting to get main_ref_store outside of repository
>
> Let's work around this, simply by ignoring the `includeif.onbranch:`
> setting when parsing the config when the ref store has not been
> initialized (yet).
I think this "fix the BUG() now, consider making more uses cases work
later" is the right thing to do, and it matches many of the other
"oops, we are looking at repository bits while not in a repo" fixes
we've done over the past few years.
> Technically, there is a way to solve this properly: teach the refs
> machinery to initialize the ref_store from a given gitdir/commondir pair
> (which we _do_ have in the early config code path), and then use that in
> `include_by_branch()`. This, however, is a pretty involved project, and
> we're already in the feature freeze for Git v2.23.0.
This gets tricky, because some commands are intentionally avoiding the
normal lookup procedure (e.g., clone or init, and probably things like
upload-pack that want to enter another repo). So I think it is OK as
long as the early-config code is explicitly saying "and please look at
the refs in this specific direectory now", and it doesn't affect other
possible code paths that might look at refs. I _think_ that's what
you're suggesting above, but I just want to make sure (not that it
matters either way for this patch).
As a workaround, I suspect in many cases it might work to simply do a
gentle setup (e.g., in "help"), but we simply weren't doing it before
because there was no use case. That obviously wouldn't work for
something like clone, though.
> diff --git a/config.c b/config.c
> index ed7f58e0fc..3900e4947b 100644
> --- a/config.c
> +++ b/config.c
> @@ -275,7 +275,8 @@ static int include_by_branch(const char *cond, size_t cond_len)
> int flags;
> int ret;
> struct strbuf pattern = STRBUF_INIT;
> - const char *refname = resolve_ref_unsafe("HEAD", 0, NULL, &flags);
> + const char *refname = !the_repository || !the_repository->gitdir ?
> + NULL : resolve_ref_unsafe("HEAD", 0, NULL, &flags);
I think the_repository is always non-NULL. The way similar sites check
this is with "!startup_info->have_repository" or have_git_dir(). The
early-config code uses the latter, so we should probably match it here.
Side note: I suspect there are some cleanup opportunities. IIRC, I had
to add have_git_dir() to cover some cases where $GIT_DIR was set but
we hadn't explicitly done a setup step, but there's been a lot of
refactoring and cleanup in the initialization code since then. I'm not
sure if it's still necessary.
> diff --git a/t/t1309-early-config.sh b/t/t1309-early-config.sh
> index 413642aa56..0c37e7180d 100755
> --- a/t/t1309-early-config.sh
> +++ b/t/t1309-early-config.sh
> @@ -89,4 +89,9 @@ test_expect_failure 'ignore .git/ with invalid config' '
> test_with_config "["
> '
>
> +test_expect_success 'early config and onbranch' '
> + echo "[broken" >broken &&
> + test_with_config "[includeif \"onbranch:refs/heads/master\"]path=../broken"
> +'
OK, so we know we didn't see the broken config because we'd have barfed
if we actually included it. Makes sense.
-Peff
