From: Patrick Steinhardt <ps@pks.im>
To: Elijah Newren <newren@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v2 5/6] bundle: get (mostly) rid of `the_repository`
Date: Fri, 21 Aug 2026 09:46:23 +0200 [thread overview]
Message-ID: <aogCTy4-DYYhS-VK@pks.im> (raw)
In-Reply-To: <CABPp-BE63m2sB4-18JUiYDK+UXaCq9z_=A8JAutvjn155_HWZA@mail.gmail.com>
On Thu, Aug 20, 2026 at 10:42:49PM -0700, Elijah Newren wrote:
> On Mon, Aug 17, 2026 at 10:26 PM Patrick Steinhardt <ps@pks.im> wrote:
> > On Mon, Aug 17, 2026 at 09:47:53AM -0700, Junio C Hamano wrote:
> > > Patrick Steinhardt <ps@pks.im> writes:
> > > > diff --git a/bundle.c b/bundle.c
> > > > index b64716f252..a9330bf0d3 100644
> > > > --- a/bundle.c
> > > > +++ b/bundle.c
> > > > @@ -1,4 +1,3 @@
> > > > -#define USE_THE_REPOSITORY_VARIABLE
> > > > #define DISABLE_SIGN_COMPARE_WARNINGS
> > > >
> > > > #include "git-compat-util.h"
> > > > @@ -21,6 +20,13 @@
> > > > #include "connected.h"
> > > > #include "write-or-die.h"
> > > >
> > > > +/*
> > > > + * NEEDSWORK: this function implicitly depends on `the_repository` and is not
> > > > + * available because we dropped USE_THE_REPOSITORY_VARIABLE. We can remove the
> > > > + * declaration once it's accessible via `repo_config_values`.
> > > > + */
> > > > +extern const char *get_log_output_encoding(void);
> > > > +
> > >
> > > Doesn't this defeat the whole "drop #define USE_THE_REPOSITORY_VARIABLE
> > > as a mark that we are done with this file and no longer need to
> > > worry about it going forward because we won't be able to compile if
> > > somebody adds a new use?" premise?
> >
> > Yes and no. By removing the define early it allows us to not reintroduce
> > new references to `the_repository` by accident, but carve out a single
> > exception for one of the functions that still depends on it. The
> > alternative would be to not do that, and if so there is no guarantee
> > whatsoever that we won't introduce more references to `the_repository`
> > in this file.
> >
> > So I'm still leaning towards keeping this as-is, but I don't feel very
> > strongly about this. Let me know in case that argument doesn't sway you
> > and I'll adapt.
>
> Would it make more sense to do this the way replay.c does:
>
> #define USE_THE_REPOSITORY_VARIABLE
> <a bunch of includes>
> /*
> * We technically need USE_THE_REPOSITORY_VARIABLE for <X>, but
> * do not want to use the_repository.
> */
> #define the_repository DO_NOT_USE_THE_REPOSITORY
>
> and remove the declaration of get_log_output_encoding() that you
> added? Alternatively, should replay.c be adapted to the way you are
> doing it here?
The benefit of removing `USE_THE_REPOSITORY_VARIABLE` completely over
stubbing out `the_repository` is that it will also remove a couple of
function declarations that implicitly rely on `the_repository`, like for
example `get_log_output_encoding()`. So I think it's a slightly better
mechainsm over redefining `the_repository`.
Patrick
next prev parent reply other threads:[~2026-08-21 7:46 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 10:45 [PATCH 0/5] odb: make packfile generation pluggable Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 1/5] odb: introduce interface to generate packfiles Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 2/5] upload-pack: generate packfiles via the object database Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 3/5] send-pack: " Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 4/5] builtin/bundle: refactor option handling for progress meter Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 5/5] bundle: generate packfiles via the object database Patrick Steinhardt
2026-08-13 18:00 ` Junio C Hamano
2026-08-14 7:40 ` Patrick Steinhardt
2026-08-07 21:05 ` [PATCH 0/5] odb: make packfile generation pluggable Junio C Hamano
2026-08-10 5:25 ` Patrick Steinhardt
2026-08-12 23:41 ` Taylor Blau
[not found] ` <an1ajMjVRUsfu-lv@pks.im>
2026-08-13 17:35 ` Junio C Hamano
2026-08-17 5:39 ` [PATCH v2 0/6] " Patrick Steinhardt
2026-08-17 5:39 ` [PATCH v2 1/6] odb: introduce interface to generate packfiles Patrick Steinhardt
2026-08-19 16:56 ` Elijah Newren
2026-08-20 6:01 ` Patrick Steinhardt
2026-08-21 4:41 ` Elijah Newren
2026-08-21 6:34 ` Patrick Steinhardt
2026-08-17 5:39 ` [PATCH v2 2/6] upload-pack: generate packfiles via the object database Patrick Steinhardt
2026-08-17 5:39 ` [PATCH v2 3/6] send-pack: " Patrick Steinhardt
2026-08-17 5:39 ` [PATCH v2 4/6] builtin/bundle: refactor option handling for progress meter Patrick Steinhardt
2026-08-17 5:39 ` [PATCH v2 5/6] bundle: get (mostly) rid of `the_repository` Patrick Steinhardt
2026-08-17 16:47 ` Junio C Hamano
2026-08-18 5:26 ` Patrick Steinhardt
2026-08-21 5:42 ` Elijah Newren
2026-08-21 7:46 ` Patrick Steinhardt [this message]
2026-08-17 5:39 ` [PATCH v2 6/6] bundle: generate packfiles via the object database Patrick Steinhardt
2026-08-19 21:52 ` Justin Tobler
2026-08-20 6:01 ` Patrick Steinhardt
2026-08-20 7:55 ` [PATCH v3 0/6] odb: make packfile generation pluggable Patrick Steinhardt
2026-08-20 7:55 ` [PATCH v3 1/6] odb: introduce interface to generate packfiles Patrick Steinhardt
2026-08-20 10:16 ` Karthik Nayak
2026-08-20 11:38 ` Patrick Steinhardt
2026-08-20 17:04 ` Junio C Hamano
2026-08-21 6:28 ` Patrick Steinhardt
2026-08-20 7:55 ` [PATCH v3 2/6] upload-pack: generate packfiles via the object database Patrick Steinhardt
2026-08-20 10:24 ` Karthik Nayak
2026-08-20 11:38 ` Patrick Steinhardt
2026-08-20 21:11 ` Karthik Nayak
2026-08-20 7:55 ` [PATCH v3 3/6] send-pack: " Patrick Steinhardt
2026-08-20 7:55 ` [PATCH v3 4/6] builtin/bundle: refactor option handling for progress meter Patrick Steinhardt
2026-08-20 11:17 ` Karthik Nayak
2026-08-20 7:55 ` [PATCH v3 5/6] bundle: get (mostly) rid of `the_repository` Patrick Steinhardt
2026-08-20 7:55 ` [PATCH v3 6/6] bundle: generate packfiles via the object database Patrick Steinhardt
2026-08-20 11:19 ` Karthik Nayak
2026-08-20 11:38 ` Patrick Steinhardt
2026-08-20 11:20 ` [PATCH v3 0/6] odb: make packfile generation pluggable Karthik Nayak
2026-08-20 11:40 ` Patrick Steinhardt
2026-08-21 6:05 ` Elijah Newren
2026-08-21 6:30 ` [PATCH v4 " Patrick Steinhardt
2026-08-21 6:30 ` [PATCH v4 1/6] odb: introduce interface to generate packfiles Patrick Steinhardt
2026-08-21 6:30 ` [PATCH v4 2/6] upload-pack: generate packfiles via the object database Patrick Steinhardt
2026-08-21 6:30 ` [PATCH v4 3/6] send-pack: " Patrick Steinhardt
2026-08-21 6:30 ` [PATCH v4 4/6] builtin/bundle: refactor option handling for progress meter Patrick Steinhardt
2026-08-21 6:30 ` [PATCH v4 5/6] bundle: get (mostly) rid of `the_repository` Patrick Steinhardt
2026-08-21 6:30 ` [PATCH v4 6/6] bundle: generate packfiles via the object database 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=aogCTy4-DYYhS-VK@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox