From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: "René Scharfe" <l.s.r@web.de>, git@vger.kernel.org
Subject: Re: [PATCH 09/10] tree: stop using the_repository
Date: Mon, 12 Jan 2026 16:00:47 +0100 [thread overview]
Message-ID: <aWUMn6G0C1cHA4qY@pks.im> (raw)
In-Reply-To: <xmqqh5sqoqr0.fsf@gitster.g>
On Mon, Jan 12, 2026 at 06:22:11AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> > On Fri, Jan 09, 2026 at 10:30:20PM +0100, René Scharfe wrote:
> >> Push the use of the_repository to the remaining callers by turning the
> >> compatibility wrappers into macros, whose use still requires
> >> USE_THE_REPOSITORY_VARIABLE to be defined.
> >
> > Can't we make this step a bit more explicit by adapting all callers to
> > parse `repo_parse_tree()` with `the_repository`? That makes it way more
> > obvious that we rely on the global repository.
> >
> > Edit: I see that you _do_ edit all callsites in the next commit, nice.
> >
> > In any case, I'd propose to move the compatibility macros into a section
> > that says something like:
> >
> > /* Deprecated wrappers that will be removed once Git 2.53 is released. */
>
> Please do not take release schedule hostage to one particular fix-up
> series of patches. Thanks.
The intent isn't really to take anything hostage. It's rather intended
as a hint that once a specific event has happened, we should take
another look at removing these wrappers.
We regularly have the case that we add compatibility wrappers to not
break in-flight patch series. We then have to wait a bit before we can
remove those wrappers, which makes it likely that we forget doing so. By
having the above marker we basically crowdsource their removal as
everyone passing by the comment will now wonder "Wait, we already have
Git 2.67, why do these wrappers still exist?".
Patrick
next prev parent reply other threads:[~2026-01-12 15:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-09 21:30 [PATCH 00/10] tree: stop using the_repository René Scharfe
2026-01-09 21:30 ` [PATCH 01/10] environment: move access to core.maxTreeDepth into repo settings René Scharfe
2026-01-12 9:21 ` Patrick Steinhardt
2026-01-12 19:37 ` René Scharfe
2026-01-09 21:30 ` [PATCH 02/10] tree: add repo_parse_tree*() René Scharfe
2026-01-09 21:30 ` [PATCH 03/10] add-interactive: use repo_parse_tree_indirect() René Scharfe
2026-01-09 21:30 ` [PATCH 04/10] bloom: use repo_parse_tree() René Scharfe
2026-01-09 21:30 ` [PATCH 05/10] delta-islands: " René Scharfe
2026-01-09 21:30 ` [PATCH 06/10] pack-bitmap-write: " René Scharfe
2026-01-09 21:30 ` [PATCH 07/10] path-walk: use repo_parse_tree_gently() René Scharfe
2026-01-09 21:30 ` [PATCH 08/10] tree: use repo_parse_tree() René Scharfe
2026-01-12 9:21 ` Patrick Steinhardt
2026-01-09 21:30 ` [PATCH 09/10] tree: stop using the_repository René Scharfe
2026-01-12 9:21 ` Patrick Steinhardt
2026-01-12 14:22 ` Junio C Hamano
2026-01-12 15:00 ` Patrick Steinhardt [this message]
2026-01-12 15:17 ` Junio C Hamano
2026-01-12 15:20 ` Junio C Hamano
2026-01-12 15:28 ` Patrick Steinhardt
2026-01-12 19:37 ` René Scharfe
2026-01-13 6:13 ` Patrick Steinhardt
2026-01-09 21:30 ` [PATCH 10/10] cocci: convert parse_tree functions to repo_ variants René Scharfe
2026-01-15 22:01 ` [PATCH 11/10] cocci: remove obsolete the_repository rules René Scharfe
2026-01-16 10:02 ` Patrick Steinhardt
2026-01-16 17:28 ` Junio C Hamano
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=aWUMn6G0C1cHA4qY@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=l.s.r@web.de \
/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