Subject: Re: [PATCH 03/18] setup: stop using `the_repository` in `is_inside_git_dir()`

From: Patrick Steinhardt <[email-masked]>
Date: Mon, 13 Apr 2026 07:47:52 +0200

On Thu, Apr 09, 2026 at 08:58:03AM -0400, Karthik Nayak wrote:
> Patrick Steinhardt <[email-masked]> writes:
> 
> > Similar as with the preceding commit, `is_inside_git_dir()` determines
> > whether the current working directory is located inside the gitdir of
> > `the_repository`. Perform the same refactoring by dropping the caching
> > mechanism and injecting the repository that shall be checked.
> >
> 
> The patch looks good. I do wonder if these functions need a new home,
> 'setup.c' is fine, but it is also bloated.

I agree that they don't really make a ton of sense in "setup.c". In
general, I would love to split up that file into two pieces:

  - The pieces required to detect a repository and discover its exact
    configuration. So scanning the current working directory and its
    parent directories, paying attention to environment variables, and
    detecting the repository format.

  - The pieces required to configure the repository based on the
    findings.

I would really like to completely detangle these two things from one
another so that the detection logic will basically just give us a
structure that contains all relevant information. And that info can then
be passed into "repository.c" to create a new repository for us based on
the info.

This would unlock a couple of benefits:

  - Creating a repository will become "pure", as we only depend on
    passed-in info and not on the environment anymore.

  - We can unify the creation of a repository into, instead of having
    roughly the same logic in both "setup.c" and "repository.c".

  - We can remove some logic that essentially re-configures a repo
    multiple times as we currently do in "setup.c", which should lead to
    a much cleaner design.

This is already thinking ahead quite a bit though. The next step would
be to de-globalize some other functionality in "setup.c" first in the
next patch series. But afterwards I'd indeed like to tackle this problem
in the subsequent step.

Thanks!

Patrick