From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
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 07:20:32 -0800 [thread overview]
Message-ID: <xmqqms2in9hb.fsf@gitster.g> (raw)
In-Reply-To: <aWUMn6G0C1cHA4qY@pks.im> (Patrick Steinhardt's message of "Mon, 12 Jan 2026 16:00:47 +0100")
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?
next prev parent reply other threads:[~2026-01-12 15:20 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 [this message]
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=xmqqms2in9hb.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=ps@pks.im \
/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