Show 33 quoted lines
> Le 10 août 2026 à 08:44, Patrick Steinhardt <ps@pks.im> 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
>> <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