Re: [PATCH 3/3] core: convert build-time USE_NSEC into runtime core.useNanosec
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Aug 10, 2026, 12:44 UTC
- Message-ID
- <annHlFwu4NKwmcLr@pks.im>
- In-Reply-To
- <CALnO6CBm4g27mWBvD9m6yL0e5YZu3M9_zcUeLZk7QwTgnxMLQA@mail.gmail.com>
On Mon, Aug 10, 2026 at 08:27:51AM -0400, D. Ben Knoble wrote: [snip]
Show 21 quoted lines
> 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 > <anlmwaEtwcCPse1N@pks.im> 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