On Sun, Jun 28, 2026 at 04:18:06AM -0400, Jeff King wrote:

On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:

quoted

quoted

So I guess if we wanted to go further it would take some digging as to
how each platform behaves, and then flipping the config.make.uname knob
for ones where it can be argued that the behavior is always reasonable.

Yeah, it would be nice indeed to figure out whether these concerns still
apply. If they do, I would argue that it might even make sense to remove
the build option completely. It doesn't really make sense in my opinion
to have a build option that nobody uses and that is subtly broken when
enabled.

I suspect it works just fine on some platforms and some filesystems
(i.e., those that actually store nanoseconds on disk). So probably Linux
with ext4 is OK. That's just guessing, though.

If I understand the original problem correctly, then doing this:

  touch foo
  ls --full-time foo
  echo 3 | sudo tee /proc/sys/vm/drop_caches
  ls --full-time foo

should be instructive. If it shows the same time for both "ls" calls,
then USE_NSEC would be fine. If it doesn't, then the system is losing
the nanosecond information when it drops the cache and has to reload
from disk (and thus USE_NSEC would cause spurious stat mismatches).

On my ext4 system, I get the same answers. So far so good.

I get the same answers with a loopback-mounted ext2 system. Which
surprised me a bit, but even unmounting and remounting the filesystem,
the nanosecond times are still there. So...I guess ext2 supports
nanoseconds.

I tried with a vfat mount, and it also works: we don't have nanoseconds
either before or after. That makes sense, and implies that modern Linux
will always be OK (because it limits the cached VFS response to what the
underlying filesystem can handle).

So...maybe this is just a non-issue these days, at least on Linux?

quoted

quoted

But that's all outside the scope of your patch here.

Kind of, I guess. If we figure that this mechanism is still subtly broken
then I'd argue that it doesn't make sense to expose the option via
Meson.

True, but AFAICT it probably is safe these days, at least one some
platforms.

Hm. That makes me wonder whether it is the completely wrong approach to
make this a build option then. If it works on some systems and only on
some filesystems, then a build option is just too coarse-grained. A
distro wouldn't really be able to ever enable the option, unless it knew
that repositories will only ever exist on a filesystem that works. Which
I guess is an assumption that no distro can make.

So instead, I wonder whether we should treat this the same as for
example "core.ignoreCase", where we only use nanosecond resolution when
opted in by the user. Ideally, if we had a way to detect brokenness, we
could even make git-init(1) set it automatically.

If so, we could unconditionally enable nanoseconds on platforms that
support them, but still have a runtime toggle for filesystems that
don't.

Patrick