git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH v2 1/1] config: work around bug with includeif:onbranch and early config
Date: Wed, 31 Jul 2019 18:02:05 -0400	[thread overview]
Message-ID: <20190731220204.GA1933@sigill.intra.peff.net> (raw)
In-Reply-To: <ea1a746113b85bde5319c410f68fe3dc75f8a328.1564603600.git.gitgitgadget@gmail.com>

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

  reply	other threads:[~2019-07-31 22:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-31 19:53 [PATCH 0/1] Make the includeif:onbranch feature more robust Johannes Schindelin via GitGitGadget
2019-07-31 19:53 ` [PATCH 1/1] config: work around bug with includeif:onbranch and early config Johannes Schindelin via GitGitGadget
2019-07-31 21:37   ` Junio C Hamano
2019-07-31 20:06 ` [PATCH v2 0/1] Make the includeif:onbranch feature more robust Johannes Schindelin via GitGitGadget
2019-07-31 20:06   ` [PATCH v2 1/1] config: work around bug with includeif:onbranch and early config Johannes Schindelin via GitGitGadget
2019-07-31 22:02     ` Jeff King [this message]
2019-07-31 22:13       ` Johannes Schindelin
2019-07-31 23:12         ` Jeff King
2019-08-01  0:49           ` Jeff King
2019-08-01 17:24             ` Jeff Hostetler
2019-08-06 12:26               ` [PATCH 0/3] the_repository initialization cleanup Jeff King
2019-08-06 12:26                 ` [PATCH 1/3] t1309: use short branch name in includeIf.onbranch test Jeff King
2019-08-06 12:27                 ` [PATCH 2/3] common-main: delay trace2 initialization Jeff King
2019-08-06 12:27                 ` [PATCH 3/3] config: stop checking whether the_repository is NULL Jeff King
2019-08-06 12:49                   ` Jeff King
2019-08-08 19:48                     ` Johannes Schindelin
2019-08-06 12:56               ` [PATCH v2 1/1] config: work around bug with includeif:onbranch and early config Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190731220204.GA1933@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).