git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 09/10] tree: stop using the_repository

From
Patrick Steinhardt <ps@pks.im>
Date
Jan 13, 2026, 06:13 UTC
Message-ID
<aWXihQ3ETjQfO6dz@pks.im>
In-Reply-To
<89e23323-7e0f-42b6-9a89-dd8a682644dd@web.de>
On Mon, Jan 12, 2026 at 08:37:03PM +0100, René Scharfe wrote:
Show 37 quoted lines
> On 1/12/26 4:28 PM, Patrick Steinhardt wrote:
> > 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.
> >      */
> 
> Forgetting to remove the three macro definitions is very cheap.
> Forgetting to remove their Coccinelle rules is a bit more expensive.
> Can add a reminder.

True indeed. We have a bunch of Coccinelle rules that are not needed anymore. We should probably do a spring cleanup of those.

Patrick
Previous: René ScharfeNext: René Scharfe
Message 14 of 25 in “tree: stop using the_repository”
  1. 00/10 tree: stop using the_repositoryRené Scharfe, Jan 9, 2026
  2. 03/10 add-interactive: use repo_parse_tree_indirect()René Scharfe, Jan 9, 2026
  3. 04/10 bloom: use repo_parse_tree()René Scharfe, Jan 9, 2026
  4. 08/10 tree: use repo_parse_tree()René Scharfe, Jan 9, 2026
  5. Patrick SteinhardtJan 12, 2026
  6. 09/10 tree: stop using the_repositoryRené Scharfe, Jan 9, 2026
  7. Patrick SteinhardtJan 12, 2026
  8. Junio C HamanoJan 12, 2026
  9. Patrick SteinhardtJan 12, 2026
  10. Junio C HamanoJan 12, 2026
  11. Junio C HamanoJan 12, 2026
  12. Patrick SteinhardtJan 12, 2026
  13. René ScharfeJan 12, 2026
  14. Patrick SteinhardtJan 13, 2026
  15. 10/10 cocci: convert parse_tree functions to repo_ variantsRené Scharfe, Jan 9, 2026
  16. 02/10 tree: add repo_parse_tree*()René Scharfe, Jan 9, 2026
  17. 01/10 environment: move access to core.maxTreeDepth into repo settingsRené Scharfe, Jan 9, 2026
  18. Patrick SteinhardtJan 12, 2026
  19. René ScharfeJan 12, 2026
  20. 07/10 path-walk: use repo_parse_tree_gently()René Scharfe, Jan 9, 2026
  21. 05/10 delta-islands: use repo_parse_tree()René Scharfe, Jan 9, 2026
  22. 06/10 pack-bitmap-write: use repo_parse_tree()René Scharfe, Jan 9, 2026
  23. 11/10 cocci: remove obsolete the_repository rulesRené Scharfe, Jan 15, 2026
  24. Patrick SteinhardtJan 16, 2026
  25. Junio C HamanoJan 16, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.