Patrick Steinhardt [off-list ref] writes:

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.

Yes and no.  Build options are not only for distro packagers who aim
for widest audience.  If you know the target box with its
filesystems happen to be OK with the option, flipping the switch to
turn it on is totally a sensible thing to do.  It is true that this
one is much less flexible (because the situation you must be in to
enable it is much narrower).

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.

I like the line of thought.

The ignoreCase MUST be set for correct operation if your filesystem
is incapable of case sensitive operation, and if your filesystem is
case sensitive, building with ignoreCase set may limit what you can
do, and give you some performace hits, but also the code can make
assumptions like "ah, we saw 'Makefile' in this directory so there
wouldn't be makefile at the same time" and misbehave).  In other
words, it is not something you set by choice.

On the other hand, nanosecond timestamp does not have to be enabled
even if your filesystem and operating system is capable of keeping
the timestamp always down to nanosecond resolution, even though it
has to be disabled if your filesystem and operating system randomly
loses precision due to buffer cache getting flushed.  So there is a
slight difference between it and the ignoreCase situation.