All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin Tobler <jltobler@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 5/7] environment: split up concerns of `is_bare_repository_cfg`
Date: Wed, 10 Jun 2026 17:22:04 -0500	[thread overview]
Message-ID: <ainesoUOuhspKxHF@denethor> (raw)
In-Reply-To: <20260610-b4-pks-setup-drop-global-state-v1-5-5dff3eec8f06@pks.im>

On 26/06/10 08:56AM, Patrick Steinhardt wrote:
> The `is_bare_repository_cfg` variable tracks two different pieces of
> information:
> 
>   - It tracks whether the user has invoked git with the "--bare" flag,
>     which makes us treat any discovered Git repository as if it was a
>     bare repository.
> 
>   - Otherwise it tracks whether the discovered `the_repository` is bare.
> 
> This makes the flag extremely confusing and creates a bit of a challenge
> when handling multiple repositories in the same process.

Indeed, this does seem rather confusing.

> Split up the concerns of this variable into two pieces:
> 
>   - `startup_info.force_bare_repository` tracks whether the user has
>     passed the "--bare" flag. This is used as a hint to treat newly set
>     up repositories as bare regardless of whether or not they have a
>     worktree.
> 
>   - `struct repository::bare_cfg` tracks whether or not a repository is
>     considered bare. This takes into account both whether the user has
>     passed "--bare" and the discovered state of the repository itself.
> 
> Whether or not a repository is bare is now resolved when checking the
> repository's format, and is then later applied to the repository itself
> via `apply_repository_format()`.

Nice. These seem like they should be tracked separately, so splitting
them up sounds like a good idea.

> This enables a subsequent change where we make `is_bare_repository()`
> not depend on global state anymore.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  builtin/init-db.c |  2 +-
>  environment.c     |  5 ++---
>  environment.h     |  1 -
>  git.c             |  2 +-
>  repository.c      |  1 +
>  repository.h      |  7 +++++++
>  setup.c           | 21 ++++++++++++++-------
>  setup.h           |  6 ++++++
>  worktree.c        |  2 +-
>  9 files changed, 33 insertions(+), 14 deletions(-)
> 
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index 52aa92fb0a..566732c9f4 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -81,7 +81,7 @@ int cmd_init_db(int argc,
>  	const char *template_dir = NULL;
>  	char *template_dir_to_free = NULL;
>  	unsigned int flags = 0;
> -	int bare = is_bare_repository_cfg;
> +	int bare = startup_info->force_bare_repository ? 1 : -1;

Any particular reason to continue mapping `force_bare_repository=false`
to -1? Or was this to just minimize changes?

>  	const char *object_format = NULL;
>  	const char *ref_format = NULL;
>  	const char *initial_branch = NULL;
[snip]
> diff --git a/repository.h b/repository.h
> index 36e2db2633..7d649e32e7 100644
> --- a/repository.h
> +++ b/repository.h
> @@ -117,6 +117,13 @@ struct repository {
>  	bool worktree_initialized;
>  	bool worktree_config_is_bogus;
>  
> +	/*
> +	 * Whether the repository is bare, as set by "core.bare" config or
> +	 * inferred during repository discovery. -1 means unset/unknown, 0
> +	 * means non-bare, 1 means bare.
> +	 */
> +	int bare_cfg;

Now we track whether a repository is bare in `struct repository` and
removes the need to a separate global to track this state.

> +
>  	/*
>  	 * Path from the root of the top-level superproject down to this
>  	 * repository.  This is only non-NULL if the repository is initialized
> diff --git a/setup.c b/setup.c
> index 71fc6b33da..2b690da8ca 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -795,10 +795,16 @@ static int check_repository_format_gently(const char *gitdir,
>  		has_common = 0;
>  	}
>  
> -	if (!has_common) {
> -		if (candidate->is_bare != -1)
> -			is_bare_repository_cfg = candidate->is_bare;
> -	} else {
> +	if (startup_info->force_bare_repository) {
> +		candidate->is_bare = 1;
> +		FREE_AND_NULL(candidate->work_tree);
> +	} else if (has_common) {
> +		/*
> +		 * When sharing a common dir with another repository (e.g. a
> +		 * linked worktree), do not let this repository's config
> +		 * dictate bareness; it is inherited from the main worktree.
> +		 */
> +		candidate->is_bare = -1;
>  		FREE_AND_NULL(candidate->work_tree);

Previously, when there was a common dir, `candidate->work_tree` was left
untouched, but now we are expclicitly setting it. I'm not sure I fully
understand this change.

-Justin

  reply	other threads:[~2026-06-10 22:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-10  6:56 [PATCH 0/7] setup: drop global state Patrick Steinhardt
2026-06-10  6:56 ` [PATCH 1/7] builtin/init: stop modifying global `git_work_tree_cfg` variable Patrick Steinhardt
2026-06-10 21:15   ` Justin Tobler
2026-06-10  6:56 ` [PATCH 2/7] builtin/init: simplify logic to configure worktree Patrick Steinhardt
2026-06-10 21:29   ` Justin Tobler
2026-06-10  6:56 ` [PATCH 3/7] setup: remove global `git_work_tree_cfg` variable Patrick Steinhardt
2026-06-10 21:52   ` Justin Tobler
2026-06-10  6:56 ` [PATCH 4/7] builtin/init: stop modifying `is_bare_repository_cfg` Patrick Steinhardt
2026-06-10  6:56 ` [PATCH 5/7] environment: split up concerns of `is_bare_repository_cfg` Patrick Steinhardt
2026-06-10 22:22   ` Justin Tobler [this message]
2026-06-10  6:56 ` [PATCH 6/7] environment: stop using `the_repository` in `is_bare_repository()` Patrick Steinhardt
2026-06-10  6:56 ` [PATCH 7/7] treewide: drop USE_THE_REPOSITORY_VARIABLE Patrick Steinhardt
2026-06-10 22:26   ` Justin Tobler

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=ainesoUOuhspKxHF@denethor \
    --to=jltobler@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=ps@pks.im \
    /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.