From: Jeff King <peff@peff.net>
Date: Tue, 01 Sep 2026 04:54:03 GMT
Subject: Re: [PATCH v6 3/3] core: convert build-time USE_NSEC into runtime core.useNanosec
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:

> 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