All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 03/18] setup: stop using `the_repository` in `is_inside_git_dir()`
Date: Mon, 13 Apr 2026 07:47:52 +0200	[thread overview]
Message-ID: <adyDiEW0-wRlgp6E@pks.im> (raw)
In-Reply-To: <CAOLa=ZS-bHiG0wyjwfzSbX4TgC_Jfpk2NXHAf=dUm6CvVxx80Q@mail.gmail.com>

On Thu, Apr 09, 2026 at 08:58:03AM -0400, Karthik Nayak wrote:
> Patrick Steinhardt <ps@pks.im> 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

  reply	other threads:[~2026-04-13  5:48 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30 13:17 [PATCH 00/18] setup: drop uses of `the_repository` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 01/18] setup: replace use of `the_repository` in static functions Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 02/18] setup: stop using `the_repository` in `is_inside_worktree()` Patrick Steinhardt
2026-04-09 11:55   ` Karthik Nayak
2026-03-30 13:17 ` [PATCH 03/18] setup: stop using `the_repository` in `is_inside_git_dir()` Patrick Steinhardt
2026-04-09 12:58   ` Karthik Nayak
2026-04-13  5:47     ` Patrick Steinhardt [this message]
2026-04-13 15:36       ` Junio C Hamano
2026-03-30 13:17 ` [PATCH 04/18] setup: stop using `the_repository` in `prefix_path()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 05/18] setup: stop using `the_repository` in `path_inside_repo()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 06/18] setup: stop using `the_repository` in `verify_filename()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 07/18] setup: stop using `the_repository` in `verify_non_filename()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 08/18] setup: stop using `the_repository` in `enter_repo()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 09/18] setup: stop using `the_repository` in `setup_work_tree()` Patrick Steinhardt
2026-04-18  1:11   ` Elijah Newren
2026-04-20  7:06     ` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 10/18] setup: stop using `the_repository` in `set_git_work_tree()` Patrick Steinhardt
2026-04-18  1:16   ` Elijah Newren
2026-04-20  7:06     ` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 11/18] setup: stop using `the_repository` in `setup_git_env()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 12/18] setup: stop using `the_repository` in `setup_git_directory_gently()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 13/18] setup: stop using `the_repository` in `setup_git_directory()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 14/18] setup: stop using `the_repository` in `upgrade_repository_format()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 15/18] setup: stop using `the_repository` in `check_repository_format()` Patrick Steinhardt
2026-04-18  1:23   ` Elijah Newren
2026-04-20  7:06     ` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 16/18] setup: stop using `the_repository` in `initialize_repository_version()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 17/18] setup: stop using `the_repository` in `create_reference_database()` Patrick Steinhardt
2026-03-30 13:17 ` [PATCH 18/18] setup: stop using `the_repository` in `init_db()` Patrick Steinhardt
2026-04-09 13:05 ` [PATCH 00/18] setup: drop uses of `the_repository` Karthik Nayak
2026-04-13  5:48   ` Patrick Steinhardt
  -- strict thread matches above, loose matches on Subject: below --
2026-04-20  8:22 Patrick Steinhardt
2026-04-20  8:22 ` [PATCH 03/18] setup: stop using `the_repository` in `is_inside_git_dir()` Patrick Steinhardt

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

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

  git send-email \
    --in-reply-to=adyDiEW0-wRlgp6E@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=karthik.188@gmail.com \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.