Re: [PATCH v6 3/3] core: convert build-time USE_NSEC into runtime core.useNanosec
From: Jeff King <hidden>
Date: 2026-09-01 04:54:05
On Mon, Aug 31, 2026 at 04:01:37PM -0400, D. Ben Knoble wrote:
quoted hunk ↗ jump to hunk
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