All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: Re: [PATCH 1/2] repository: make repo_clear() idempotent
Date: Wed, 2 Sep 2026 02:29:40 -0400	[thread overview]
Message-ID: <20260902062940.GA47676@coredump.intra.peff.net> (raw)
In-Reply-To: <20260902055526.GA41747@coredump.intra.peff.net>

On Wed, Sep 02, 2026 at 01:55:27AM -0400, Jeff King wrote:

> Arguably this should not be a pointer at all, but the pool code is
> weirdly asymmetric. It offers only "new" which allocates a struct, but
> only "clear" to clean it up (but not deallocate). Might be worth fixing,
> but out of scope for this series.

I took a quick stab at this, and it gets ugly. There is no mutual
recursion between the parsed_object_pool and repository struct
definitions, but we do end up in a header include loop:

  - repository.h would need object.h (to include the pool struct)

  - object.h includes hash.h for object_id, etc

  - hash.h (sometimes) includes repository.h so it can define
    the_hash_algo when USE_THE_REPOSITORY_VARIABLE is defined

We could break the cycle if we had a separate the-repository.h which
looked like this:

  struct repository;
  extern struct repository *the_repository;

and then included that from hash.h. But then callers which want to use
the_hash_algo would need to include repository.h themselves. It is
just a macro looking at the_repository->hash_algo, so they need the
actual repository definition. About 9 files need to start including
repository.h themselves to make it work. Though a few of them _ought_ to
be including it anyway; they are not using the_hash_algo at all, but
just lucky that hash.h happens to bring repository.h when
USE_THE_REPOSITORY_VARIABLE is set.

An alternative would be to define the_hash_algo as its own pointer,
like:

diff --git a/hash.h b/hash.h
index cf94ad5700..9e21ac6480 100644
--- a/hash.h
+++ b/hash.h
@@ -269,8 +269,7 @@ enum get_oid_result {
 };
 
 #ifdef USE_THE_REPOSITORY_VARIABLE
-# include "repository.h"
-# define the_hash_algo the_repository->hash_algo
+extern struct git_hash_algo *the_hash_algo;
 #endif
 
 /* A suitably aligned type for stack allocations of hash contexts. */
diff --git a/repository.c b/repository.c
index db4f9d006e..f70c4deecf 100644
--- a/repository.c
+++ b/repository.c
@@ -30,6 +30,7 @@ extern struct repository *the_repository;
 /* The main repository */
 static struct repository the_repo;
 struct repository *the_repository = &the_repo;
+struct the_hash_algo = &the_repo->hash_algo;
 
 /*
  * An escape hatch: if we hit a bug in the production code that fails


That makes the_hash_algo just work without most code caring about
repositories at all. But of course it reveals yet more spots which are
relying on hash.h mentioning the_repository. :-/

I'm not sure how much it's worth untangling all of this, but probably
not enough just to remove pointer indirection from repo->parsed_objects.

-Peff

  reply	other threads:[~2026-09-02  6:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02  5:51 [PATCH 0/2] fix a leak in submodule error path Jeff King
2026-09-02  5:55 ` [PATCH 1/2] repository: make repo_clear() idempotent Jeff King
2026-09-02  6:29   ` Jeff King [this message]
2026-09-02  6:49     ` Jeff King
2026-09-02  9:11       ` Patrick Steinhardt
2026-09-02 16:29         ` Junio C Hamano
2026-09-03  5:15           ` Patrick Steinhardt
2026-09-02  5:57 ` [PATCH 2/2] submodule--helper: free URL when repository setup fails Jeff King
2026-09-02  9:11   ` 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=20260902062940.GA47676@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    /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.