Git development
 help / color / mirror / Atom feed
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

  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