Thread (66 messages) flat view 66 messages, 5 authors, 7d ago

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

From: D. Ben Knoble <hidden>
Date: 2026-08-14 19:04:07

On Fri, Aug 14, 2026 at 12:38 PM Junio C Hamano [off-list ref] wrote:
"D. Ben Knoble" [off-list ref] writes:
quoted
-#ifdef USE_NSEC
-     if (cfg->check_stat && sd->sd_mtime.nsec != ST_MTIME_NSEC(*st))
-             changed |= MTIME_CHANGED;
-     if (cfg->trust_ctime && cfg->check_stat &&
-         sd->sd_ctime.nsec != ST_CTIME_NSEC(*st))
-             changed |= CTIME_CHANGED;
-#endif
+     if (cfg->use_nanosec) {
+             if (cfg->check_stat && sd->sd_mtime.nsec != ST_MTIME_NSEC(*st))
+                     changed |= MTIME_CHANGED;
+             if (cfg->trust_ctime && cfg->check_stat &&
+                 sd->sd_ctime.nsec != ST_CTIME_NSEC(*st))
+                     changed |= CTIME_CHANGED;
+     }

      if (cfg->check_stat) {
              if (sd->sd_uid != (unsigned int) st->st_uid ||
This is iffy.

If you have core.usenanosec=true in a networked $HOME/.gitconfig
mounted on both USE_NSEC-capable and incapable platforms, what would
ST_CTIME_NSEC() yield on the latter?
Perhaps "if it hurts, don't do that"? This config is definitely about
exposing the underlying system's capabilities to Git, so if you cannot
confidently do so globally, you probably shouldn't. That might limit
the usefulness of the optimization for folks that share filesystems
between multiple machines in this way, I suppose. Or maybe it will
incentivize folks to be nsec-compatible in more places ;) Either way,
users that can benefit from it will have the option.
I wonder if cfg's
'.use_nanosec' should be force-disabled in NO_NSEC builds, or
something similar?
This does, however, make some sense to me:

- Git today with NO_NSEC doesn't bother with the USE_NSEC paths, since
we #undef USE_NSEC in that case.
- Git "tomorrow" should probably say "I was built with NO_NSEC, so I
will (continue) ignoring platform-specific nanosecond optimizations."

I'll queue this change locally until I send out the next version,
unless someone objects.

-- 
D. Ben Knoble
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help