Re: [PATCH v3] setup: trace bare repository setups

From: Josh Steadmon <steadmon@google.com>
Date: May 10, 2023, 23:29 UTC
Message-ID: <ZFwop6NTThvLKOU3@google.com>
In-Reply-To: <ZFl4UVhoR4Hlm2g3@nand.local>

On 2023.05.08 18:31, Taylor Blau wrote:

Show 13 quoted lines

> On Fri, May 05, 2023 at 03:30:38PM -0700, Junio C Hamano wrote:
> > Thanks.  We saw no interest on the list in reviewing this patch
> > further, it seems, but I didn't see anything glaringly wrong, see
> > no reason not to merge it, and this should help noticing potential
> > issues by $corp folks, I would presume, so let's merge it as-is.
> 
> I took a look through this thread and would be fine to see this one
> picked up, though I did have a couple of questions:
> 
>   - Is the plan to eventually disable $GIT_DIR discovery in bare
>     repositories by default in a future version? I am still uncertain
>     of the assumption that most end-users don't interact with bare
>     repositories directly.

I think at some point in the future, we'd like for `safe.bareRepository=explicit` to be the default. To get to a state where we're comfortable making that change, we plan in the near-ish future to flip the default when `feature.experimental` is enabled.

Show 10 quoted lines

>     Certainly forges touch bare repositories without always setting
>     $GIT_DIR in their environment. But I would imagine that other tools
>     indirectly touch bare repositories on behalf of the user. You
>     mentioned "go" as one such tool that doesn't set $GIT_DIR, I imagine
>     there are many more.
> 
>   - If it is the plan to disable $GIT_DIR discovery in bare repositories
>     in the future, I'm not sure how visible the extra trace line would
>     be. Perhaps that is desirable, since having an advise() call on
>     every Git invocation in a bare repository would be noisy.

Yeah, this is mainly to help us plan for our internal rollout of `safe.bareRepository=explicit` at $DAYJOB, but we assume it would be helpful for others who might also be considering this, or for developers of affected tooling when they receive a bug report that bareRepository breaks their users.

We also want to add some more detailed tracing in general around repo/worktree initialization, but that part is not so urgent.