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

Re: [PATCH 5/5] use repo_hold_lock_file_for_update{,_mode,_timeout}() with custom repos

From
Patrick Steinhardt <ps@pks.im>
Date
Jul 21, 2026, 22:03 UTC
Message-ID
<al_spOloKmeCp0oe@pks.im>
In-Reply-To
<xmqqmrvmn6a5.fsf@gitster.g>
On Sun, Jul 19, 2026 at 12:11:46PM -0700, Junio C Hamano wrote:
Show 29 quoted lines
> René Scharfe <l.s.r@web.de> writes:
> 
> > On 7/15/26 11:52 AM, Patrick Steinhardt wrote:
> >> On Tue, Jul 14, 2026 at 07:59:56PM +0200, René Scharfe wrote:
> >>> Apply the config setting core.sharedRepository from the repository at
> >>> hand instead of from the_repository.
> >> 
> >> We only do this for a subset of callsites, apparently. How did you
> >> select which subsystems to convert and which not to? To make this
> >> explicit: I don't mind a partial migration, but I think the commit
> >> message should briefly explain the reasoning behind it.
> >
> > All those that have a repository reference other than the_repository.
> >
> >> Also, as you don't get rid of the old functions that still implicitly
> >> depend on `the_repository`, I think we should have an additional commit
> >> on top that guards all functions that have this implicit dependency with
> >> `USE_THE_REPOSITORY_VARIABLE`. This ensures that we cannot accidentally
> >> call such functions from other subsystems that already got rid of the
> >> global dependency.
> >
> > Probably, but the lockfile conversions deserve their own patch series.
> > Patch 5 is only included here because it was easy to write.  We can drop
> > it and leave the low-hanging fruit on the tree if that's preferable.
> 
> I am personally indifferent as to what we do immediately in this
> series, as long as we all agree on the longer-term direction.  It
> seems we are in agreement on providing additional safety in the
> medium term?

It would be an easy thing to guard existing interfaces that depend on `the_repository` behind `USE_THE_REPOSITORY_VARIABLE`. But the patch series is already a strict improvement over the status quo, so I don't mind if we merge it as-is and defer that to a later point.

Thanks!
Patrick
Previous: Junio C HamanoNext: Junio C Hamano
Message 13 of 15 in “tempfile: stop using the_repository”
  1. 0/5 tempfile: stop using the_repositoryRené Scharfe, Jul 14, 2026
  2. 1/5 tempfile: add repo_create_tempfile{,_mode}()René Scharfe, Jul 14, 2026
  3. Patrick SteinhardtJul 15, 2026
  4. René ScharfeJul 15, 2026
  5. 2/5 refs/packed: use repo_create_tempfile()René Scharfe, Jul 14, 2026
  6. 3/5 lockfile: add repo_hold_lock_file_for_update{,_timeout}{,_mode}()René Scharfe, Jul 14, 2026
  7. 4/5 tempfile: stop using the_repositoryRené Scharfe, Jul 14, 2026
  8. Patrick SteinhardtJul 15, 2026
  9. 5/5 use repo_hold_lock_file_for_update{,_mode,_timeout}() with custom reposRené Scharfe, Jul 14, 2026
  10. Patrick SteinhardtJul 15, 2026
  11. René ScharfeJul 18, 2026
  12. Junio C HamanoJul 19, 2026
  13. Patrick SteinhardtJul 21, 2026
  14. Junio C HamanoJul 14, 2026
  15. Patrick SteinhardtJul 15, 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.