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

From: Jeff King <peff@peff.net>
Date: Sep 1, 2026, 04:54 UTC
Message-ID: <20260901045403.GA1075462@coredump.intra.peff.net>
In-Reply-To: <0a611f614041b165140da7f2546c058178cdbfce.1788206466.git.ben.knoble@gmail.com>

On Mon, Aug 31, 2026 at 04:01:37PM -0400, D. Ben Knoble wrote:

Show 14 quoted lines

> diff --git a/environment.c b/environment.c
> index 6676e6f5ae..c83cf44839 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -571,6 +571,13 @@ int git_default_core_config(const char *var, const char *value,
>  		return 0;
>  	}
>  
> +#ifndef NO_NSEC
> +	if (!strcmp(var, "core.usenanosec")) {
> +		cfg->use_nanosec = git_config_bool(var, value);
> +		return 0;
> +	}
> +#endif

This hunk made me wonder if we even need to do any build-time magic here at all. If your platform doesn't support nanosecond stat entries, then you're probably not going to ask for core.usenanosec in the first place. But if you do, I think the code still works; we fake the entries as "0", so they'd always yield a racy tie, just as if core.usenanosec was disabled.

I guess you might be able to get into a funny state, though, if you build two versions of Git, one with NO_NSEC and one without, on a system that actually does support nanosecond timestamps. Because IIRC even if we aren't _using_ the values, we still store them in the index. So an index generated with the regular build would store the actual nanosec stamps, which would then get a false comparison using the NO_NSEC version.

That seems quite unlikely to happen in practice, and there is a certain amount of "if it hurts, don't do that". But it's not like by dropping this #ifndef we could get rid of NO_NSEC. So it would not simplify the code overall, nor the number of build knobs that we expose to the user. So it probably is reasonable to keep it.

I haven't been following the topic closely, but from my cursory read everything else looked as I'd expect it to.

-Peff