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

On Sun, Jul 19, 2026 at 12:11:46PM -0700, Junio C Hamano wrote:
> René Scharfe <[email protected]> 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