Re: [PATCH 3/3] core: convert build-time USE_NSEC into runtime core.useNanosec

On Tue, Aug 11, 2026 at 12:26 PM Ben Knoble <[email protected]> wrote:
>
>
> > Le 10 août 2026 à 08:44, Patrick Steinhardt <[email protected]> a écrit :
> >
> > On Mon, Aug 10, 2026 at 08:27:51AM -0400, D. Ben Knoble wrote:
> > [snip]
> >> Back down to being on-par with original code. So that's good. The next
> >> version will include some variant that reads a struct member instead
> >> of going through repo_config_get_bool().
> >>
> >> But which? Reading the private_ member is obviously wrong; I suppose
> >> I'm supposed to use repo_config_values() there. Or, rework the series
> >> to put this member in repo_settings. I think I originally assumed that
> >> struct is for things that are settings that aren't configured by
> >> git-config, but… now I'm not sure. Looking at prepare_repo_settings()
> >> shows lots of repo_cfg_*() calls. So I think I see how to adapt to
> >> using repo_settings,
> >>
> >> Patrick, Junio, and Tian had a brief discussion in
> >> <[email protected]> about the split creating confusion. I don't
> >> really want to wait for it to settle to land this change, but we might
> >> want to work together on identifying the best path forward for
> >> core.useNanosec :)
> >>
> >> I don't suppose it really matters to me which struct I put the member
> >> in. As I said, v2 will definitely fix the hot path lookup here. Just a
> >> matter of input on which struct we want to use this time, I guess.
> >
> > I think `repo_config_values()` is the modern variant that we're slowly
> > migrating stuff into. But that struct only works with `the_repository`,
> > so the question is whether we ever use "core.useNsec" for a different
> > repository. My hunch would be yes, for example when recusing into
> > submodules, but I'm not sure.
> >
> > Patrick
>
> Thanks. I’m working on control-flow analysis to see what kinds of repo values end up there. Of course I’ll also run the test suite and so on with the repo_config_values change. But the analysis will take some time.

Ok, CI run: https://github.com/benknoble/git/actions/runs/31701945211.
This demonstrates that nothing our test suite does across the many CI
configurations ends up where with a non-the_repository-repository
(ahem).

I have been working on control-flow analysis by hand in my Git time
this week. It's of the form "Z calls Y calls X …" until we can see
what the repository that's (eventually) fed to repo_config_values()
here in is_racy_stat() is. My notes are one node per line, which
indentation showing callee relationships. Some lines are pointers to
other nodes to avoid duplicating work.

With that in mind, filtering out the pointer nodes, I've analyzed 214
nodes in the graph. If I'm lucky, I'm approaching the halfway mark,
but I somewhat doubt it.

But since CI shows things work… I'd rather not continue the analysis
if we're satisfied for now. (Esp. since that will give me more Git
time back for reviewing ;) It being outside-of-work time, I only have
so much of it.)

A few other related things:
- Some of the edges of the graph appear to be public libgit.a
interfaces. That means we can't guarantee that only the_repository is
used.
- On a related note, I don't know how large the current "must only use
the_repository" (e.g., via repo_config_values()) surface area is right
now. Based on the partial analysis I mentioned above, this feels like
it's introducing (or at least contributing to) a rather large surface
area. So, this change might make it more critical to resolve the
limitation mentioned in the other thread. OTOH, I don't think this
change is likely to represent the only pervasive the_repository-only
limitation, and I'm afraid it will never land if it must be
the_repository clean (unless repo_settings is the_repository clean and
we decide that's an acceptable place for this member).

So, idk. If we're happy with the CI run + use of repo_config_values()
overall, I can send a v2 shortly (in next 24h), I think.

Thoughts? Strong opinions?

-- 
D. Ben Knoble