git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 1/1] config: work around bug with includeif:onbranch and early config

From
Jeff King <peff@peff.net>
Date
Jul 31, 2019, 22:02 UTC
Message-ID
<20190731220204.GA1933@sigill.intra.peff.net>
In-Reply-To
<ea1a746113b85bde5319c410f68fe3dc75f8a328.1564603600.git.gitgitgadget@gmail.com>
On Wed, Jul 31, 2019 at 01:06:42PM -0700, Johannes Schindelin via GitGitGadget wrote:
Show 19 quoted lines
> 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.

Show 5 quoted lines
> 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.

Show 11 quoted lines
> 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.
Show 12 quoted lines
> 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
Previous: Johannes Schindelin via GitGitGadgetNext: Johannes Schindelin
Message 6 of 17 in “Make the includeif:onbranch feature more robust”
  1. 0/1 Make the includeif:onbranch feature more robustJohannes Schindelin via GitGitGadget, Jul 31, 2019
  2. 1/1 config: work around bug with includeif:onbranch and early configJohannes Schindelin via GitGitGadget, Jul 31, 2019
  3. Junio C HamanoJul 31, 2019
  4. 0/1 Make the includeif:onbranch feature more robustJohannes Schindelin via GitGitGadget, Jul 31, 2019
  5. 1/1 config: work around bug with includeif:onbranch and early configJohannes Schindelin via GitGitGadget, Jul 31, 2019
  6. Jeff KingJul 31, 2019
  7. Johannes SchindelinJul 31, 2019
  8. Jeff KingJul 31, 2019
  9. Jeff KingAug 1, 2019
  10. Jeff HostetlerAug 1, 2019
  11. 0/3 the_repository initialization cleanupJeff King, Aug 6, 2019
  12. 1/3 t1309: use short branch name in includeIf.onbranch testJeff King, Aug 6, 2019
  13. 2/3 common-main: delay trace2 initializationJeff King, Aug 6, 2019
  14. 3/3 config: stop checking whether the_repository is NULLJeff King, Aug 6, 2019
  15. Jeff KingAug 6, 2019
  16. Johannes SchindelinAug 8, 2019
  17. Jeff KingAug 6, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.