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

From: Ben Knoble <ben.knoble@gmail.com>
Date: Sep 3, 2026, 18:16 UTC
Message-ID: <D0BA1B32-1CAD-4328-A612-75A648413017@gmail.com>
In-Reply-To: <xmqqbjaefhwo.fsf@gitster.g>

Show 22 quoted lines

> Le 3 sept. 2026 à 11:56, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> Ben Knoble <ben.knoble@gmail.com> writes:
> 
>>> I still am worried that something that sits this deep in the
>>> callchain can easily BUG() when working on a repository that is not
>>> the_repository due to the use of repo_config_values(), and we might
>>> be better off adopting safe default when istate->repo is different
>>> from the_repository, but other than that, I think the series is in
>>> great shape.
>>> 
>>> Thanks.
> 
>> Yea. See previous messages re: convincing the test apparatus to
>> set this globally. If I could run it that way at least locally, it
>> would go a little ways towards scaring those BUGs out into the
>> light.
> 
> I am not worried too much about the current code.  I am more worried
> about how much this will hinder future development of new features,
> e.g., diff or status recursively going into submodules without
> spawning subprocesses, which is done for grep already.

Sure. Some kind of safe default could alleviate that. But seeing recent work in these areas convinces me that we should use this as impetus to lift the restriction, and I worry that papering over it will remove that impetus. Still, if a later series needs such a band-aid, I suppose it can add the safe fallback. And that’s where testing would be nice for automatic feedback on new such interactions.

> Testing and
> seeing 'git grep --recurse-submodule' not hitting a BUG() does not
> assure us all that much, as I do not think it needs to deal with
> racily clean entries any specially.

A prior reply of mine to Patrick specifically mentioned diff with submodules, I believe. But I agree that positive evidence is probably better than negative evidence.

All-in-all, I’m not inclined to change the shape of this series at the present point in this discussion, but if you (or others) feel strongly about this « safe default » being a requirement, I will find some time eventually.