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:28:53 +0100 [thread overview]
Message-ID: <aWUTNU7WGTwHt6Ks@pks.im> (raw)
In-Reply-To: <xmqqms2in9hb.fsf@gitster.g>
On Mon, Jan 12, 2026 at 07:20:32AM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
>
> >> > 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.
>
> I am OK with a comment that records the intent, e.g., "let's work
> towards reducing the use of these wrappers", with the plan for the
> next step, e.g., "and once we have done so, remove these."
>
> But the comment you wrote is forcing people to make sure we remove
> the code that uses these wrappers and unless we finish it we cannot
> release 2.53, no?
That's definitely not my intent. It's really only intended as a hint
when those should be removed at the earliest. Maybe something like the
following instead?
/*
* These wrappers can be removed once Git 2.53 is released. If you
* see this comment and that release has been published then chances
* are high that we forgot to remove them.
*/
Patrick
next prev parent reply other threads:[~2026-01-12 15:28 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
2026-01-12 15:17 ` Junio C Hamano
2026-01-12 15:20 ` Junio C Hamano
2026-01-12 15:28 ` Patrick Steinhardt [this message]
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=aWUTNU7WGTwHt6Ks@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 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.