Volume XXII, number 279Tuesday, October 6, 2026Latest message 38 minutes ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

patchmeson: wire up USE_NSEC build knob

19 messages between Jun 20, 2026 and Jul 13, 2026, from D. Ben Knoble, Junio C Hamano, Jeff King, Patrick Steinhardt, brian m. carlson, Ben Knoble.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

D. Ben KnobleJun 20, 2026, 16:00 UTC on lore

Autotools-style builds permit enabling USE_NSEC for cases where that's desired; the equivalent knob is missing from meson-based builds.

Signed-off-by: D. Ben Knoble <ben.knoble+github@gmail.com>
---
 meson.build       | 4 ++++
 meson_options.txt | 2 ++
 2 files changed, 6 insertions(+)
Show changes to 2 files +6 −0

meson.build, meson_options.txt

diff --git a/meson.build b/meson.build
index 3247697f74..85a11119c5 100644
--- a/meson.build
+++ b/meson.build
@@ -838,6 +838,10 @@ if help_format_opt != 'man'
     libgit_c_args += '-DDEFAULT_HELP_FORMAT="' + help_format_opt + '"'
 endif
 
+if get_option('nanosec')
+  libgit_c_args += '-DUSE_NSEC'
+endif
+
 libgit_include_directories = [ '.' ]
 libgit_dependencies = [ ]
 
diff --git a/meson_options.txt b/meson_options.txt
index d936ada098..1bc75278a8 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -21,6 +21,8 @@ option('runtime_prefix', type: 'boolean', value: false,
   description: 'Resolve ancillary tooling and support files relative to the location of the runtime binary instead of hard-coding them into the binary.')
 option('sane_tool_path', type: 'array', value: [],
   description: 'An array of paths to pick up tools from in case the normal tools are broken or lacking.')
+option('nanosec', type: 'boolean', value: false,
+  description: 'Care about sub-second file mtimes and ctimes.')
 
 # Build information compiled into Git and other parts like documentation.
 option('build_date', type: 'string', value: '',

base-commit: 0c8ab3ebcc76981376809c8fe632d0fe18e93347

-- 
2.55.0.rc0.738.g0c8ab3ebcc.dirty
Junio C HamanoJun 21, 2026, 01:01 UTC in reply to D. Ben Knoble on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

"D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
> Autotools-style builds permit enabling USE_NSEC for cases where that's
> desired; the equivalent knob is missing from meson-based builds.

With or without autoconf, Makefile based build can use USE_NSEC. It is a welcome addition to the other side of thw world. I do not know if 'meson setup -Dnanosec=true' is a name that is easy to discover, though.

Will queue.  Thanks.
D. Ben KnobleJun 21, 2026, 16:41 UTC in reply to Junio C Hamano on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Sat, Jun 20, 2026 at 9:01 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 7 quoted lines
>
> "D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
>
> > Autotools-style builds permit enabling USE_NSEC for cases where that's
> > desired; the equivalent knob is missing from meson-based builds.
>
> With or without autoconf, Makefile based build can use USE_NSEC.

Thanks. I almost wrote "Make-based," but I wasn't sure how we preferred to describe it.

Show 6 quoted lines
> It
> is a welcome addition to the other side of thw world.  I do not know
> if 'meson setup -Dnanosec=true' is a name that is easy to discover,
> though.
>
> Will queue.  Thanks.
Agreed for the name. Alternatives welcome.
Jeff KingJun 21, 2026, 17:49 UTC in reply to D. Ben Knoble on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Sat, Jun 20, 2026 at 12:00:24PM -0400, D. Ben Knoble wrote:
> Autotools-style builds permit enabling USE_NSEC for cases where that's
> desired; the equivalent knob is missing from meson-based builds.

Seems reasonable. This is not changing the defaults at all, but just bringing meson's options to parity with the Makefile.

I'm not still not sure if turning on USE_NSEC is a good idea. There's some discussion in Documentation/technical/racy-git.adoc:

  With `USE_NSEC`
  compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`
  members are also compared. On Linux, this is not enabled by default
  because in-core timestamps can have finer granularity than
  on-disk timestamps, resulting in meaningless changes when an
  inode is evicted from the inode cache.  See commit 8ce13b0
  of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
  ([PATCH] Sync in core time granularity with filesystems,
  2005-01-04). This patch is included in kernel 2.6.11 and newer, but
  only fixes the issue for file systems with exactly 1 ns or 1 s
  resolution. Other file systems are still broken in current Linux
  kernels (e.g. CEPH, CIFS, NTFS, UDF), see
  https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/

That's the most succinct description of the problem I've seen, but I have no idea how widely it still applies. Kernel 2.6.11 is quite old now, but I could believe that other filesystems (especially network ones) still exhibit the issue.

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.

But that's all outside the scope of your patch here.
-Peff
Patrick SteinhardtJun 22, 2026, 08:13 UTC in reply to Junio C Hamano on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Sat, Jun 20, 2026 at 06:01:25PM -0700, Junio C Hamano wrote:
Show 9 quoted lines
> "D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
> 
> > Autotools-style builds permit enabling USE_NSEC for cases where that's
> > desired; the equivalent knob is missing from meson-based builds.
> 
> With or without autoconf, Makefile based build can use USE_NSEC.  It
> is a welcome addition to the other side of thw world.  I do not know
> if 'meson setup -Dnanosec=true' is a name that is easy to discover,
> though.

I think the name itself is fine. As is the case for other options, it can be discovered rather easily by just running `meson setup` in the source directory, which gives you an overview of all available build options.

Patrick
Patrick SteinhardtJun 22, 2026, 08:13 UTC in reply to Jeff King on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Sun, Jun 21, 2026 at 01:49:34PM -0400, Jeff King wrote:
Show 7 quoted lines
> On Sat, Jun 20, 2026 at 12:00:24PM -0400, D. Ben Knoble wrote:
> 
> > Autotools-style builds permit enabling USE_NSEC for cases where that's
> > desired; the equivalent knob is missing from meson-based builds.
> 
> Seems reasonable. This is not changing the defaults at all, but just
> bringing meson's options to parity with the Makefile.

I was originally wondering whether I should recommend that Meson can auto-discover the availability of nanoseconds. But your below remarks make me question that.

Show 25 quoted lines
> I'm not still not sure if turning on USE_NSEC is a good idea. There's
> some discussion in Documentation/technical/racy-git.adoc:
> 
>   With `USE_NSEC`
>   compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`
>   members are also compared. On Linux, this is not enabled by default
>   because in-core timestamps can have finer granularity than
>   on-disk timestamps, resulting in meaningless changes when an
>   inode is evicted from the inode cache.  See commit 8ce13b0
>   of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
>   ([PATCH] Sync in core time granularity with filesystems,
>   2005-01-04). This patch is included in kernel 2.6.11 and newer, but
>   only fixes the issue for file systems with exactly 1 ns or 1 s
>   resolution. Other file systems are still broken in current Linux
>   kernels (e.g. CEPH, CIFS, NTFS, UDF), see
>   https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/
> 
> That's the most succinct description of the problem I've seen, but I
> have no idea how widely it still applies. Kernel 2.6.11 is quite old
> now, but I could believe that other filesystems (especially network
> ones) still exhibit the issue.
> 
> 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.

> 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.

Patrick
Jeff KingJun 28, 2026, 08:18 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:
Show 9 quoted lines
> > 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?
Show 5 quoted lines
> > 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.

-Peff
Jeff KingJun 28, 2026, 08:48 UTC in reply to Jeff King on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Sun, Jun 28, 2026 at 04:18:07AM -0400, Jeff King wrote:
Show 6 quoted lines
> 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?
Oh, I also ran across this old thread:
  https://public-inbox.org/git/5605D88A.20104%40gmail.com/
that implies similar:
  * In-core file times may not be properly rounded to on-disk
    precision, causing spurious file time changes when the cache is
    refreshed from disk. This was fixed for typical Unix file systems
    in kernel 2.6.11. The fix for CEPH, CIFS, NTFS, UFS and FUSE will
    be in kernel 4.3. There's no fix for FAT-based file systems yet.

I also tested with CIFS on my system and it is fine. It looks like FAT systems were fixed since 2015. ;)

But there is another interesting question raised there, which is how different implementations may interact (e.g., two versions of Git without and without USE_NSEC, or JGit which may have to use millisecond-resolution APIs, etc). It should all work correctly as long as each implementation consistently uses its own resolution (so JGit would have to compare in millisecond-space and treat ties as racy). And I think that is _probably_ what is happening now, since we already store nanoseconds unconditionally (and only use them with USE_NSEC).

Though the opposite case is a performance problem but not a correctness one: if JGit writes out an index with milliseconds and USE_NSEC Git tries to read it, we will consider everything stat-dirty and re-read the contents.

I don't know if these would be a problem in practice or not, but it's an interesting potential gotcha. And one that nobody may have noticed, because probably hardly anybody bothers to build with USE_NSEC now.

-Peff
brian m. carlsonJun 29, 2026, 00:23 UTC in reply to Jeff King on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On 2026-06-28 at 08:48:15, Jeff King wrote:
Show 32 quoted lines
> Oh, I also ran across this old thread:
> 
>   https://public-inbox.org/git/5605D88A.20104%40gmail.com/
> 
> that implies similar:
> 
>   * In-core file times may not be properly rounded to on-disk
>     precision, causing spurious file time changes when the cache is
>     refreshed from disk. This was fixed for typical Unix file systems
>     in kernel 2.6.11. The fix for CEPH, CIFS, NTFS, UFS and FUSE will
>     be in kernel 4.3. There's no fix for FAT-based file systems yet.
> 
> I also tested with CIFS on my system and it is fine. It looks like FAT
> systems were fixed since 2015. ;)
> 
> But there is another interesting question raised there, which is how
> different implementations may interact (e.g., two versions of Git
> without and without USE_NSEC, or JGit which may have to use
> millisecond-resolution APIs, etc). It should all work correctly as long
> as each implementation consistently uses its own resolution (so JGit
> would have to compare in millisecond-space and treat ties as racy). And
> I think that is _probably_ what is happening now, since we already store
> nanoseconds unconditionally (and only use them with USE_NSEC).
> 
> Though the opposite case is a performance problem but not a correctness
> one: if JGit writes out an index with milliseconds and USE_NSEC Git
> tries to read it, we will consider everything stat-dirty and re-read the
> contents.
> 
> I don't know if these would be a problem in practice or not, but it's an
> interesting potential gotcha. And one that nobody may have noticed,
> because probably hardly anybody bothers to build with USE_NSEC now.

I would suggest that we provide a config knob and then build with USE_NSEC by default. Most people are using Linux with typical Unix file systems, NTFS, CIFS, or FUSE (e.g., sshfs). In the event someone detects a problem, there's an easy solution—adjust the knob—and we can then add a Linux-specific statfs call to determine if the file system is a safe one in a future version.

-- 
brian m. carlson (they/them)
Toronto, Ontario, CA
Patrick SteinhardtJun 29, 2026, 06:08 UTC in reply to Jeff King on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Sun, Jun 28, 2026 at 04:18:06AM -0400, Jeff King wrote:
Show 50 quoted lines
> On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:
> 
> > > 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?
> 
> > > 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
Junio C HamanoJun 29, 2026, 21:38 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

Patrick Steinhardt <ps@pks.im> writes:
Show 6 quoted lines
> 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.

Jeff KingJun 30, 2026, 05:43 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Mon, Jun 29, 2026 at 08:08:42AM +0200, Patrick Steinhardt wrote:
Show 14 quoted lines
> > 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.

Yeah, this came up earlier in the thread. It would be nice if we could set it automatically, but I'm not sure we have a good way of testing a particular filesystem. I think the sequence is:

  1. stat() a file, getting nanoseconds
  2. somehow flush the kernel's in-core inode cache
  3. stat() it again and compare

Step 2 is the tricky part. ;) It's not only not portable, but probably something that would annoy users if we did it for every repo creation.

It would also be nice if we could actually verify that the sequence above _does_ show the problem. I was not able to come up with a failing instance on my modern Linux machine (even going as far as unmounting and re-mounting for step 2).

But I do agree in general that it should be a config flag and not a build option. Run-time flags are more friendly to users when there is no good reason to avoid them.

-Peff
D. Ben KnobleJul 3, 2026, 15:46 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

[with apologies for the delay; I wasn't paying attention to "What's cooking" to notice that this was waiting on my response.]

On Mon, Jun 22, 2026 at 4:13 AM Patrick Steinhardt <ps@pks.im> wrote:
Show 9 quoted lines
>
> On Sun, Jun 21, 2026 at 01:49:34PM -0400, Jeff King wrote:
> > On Sat, Jun 20, 2026 at 12:00:24PM -0400, D. Ben Knoble wrote:
> >
> > > Autotools-style builds permit enabling USE_NSEC for cases where that's
> > > desired; the equivalent knob is missing from meson-based builds.
> >
> > Seems reasonable. This is not changing the defaults at all, but just
> > bringing meson's options to parity with the Makefile.

For now, I still think this makes me in favor of the patch: source distributions like Gentoo can then offer the build knob for those who, in Junio's words

> know the target box with its filesystems happen to be OK with the option

Otherwise, the discussion would suggest removing it from Makefile as an option :)

Show 43 quoted lines
> I was originally wondering whether I should recommend that Meson can
> auto-discover the availability of nanoseconds. But your below remarks
> make me question that.
>
> > I'm not still not sure if turning on USE_NSEC is a good idea. There's
> > some discussion in Documentation/technical/racy-git.adoc:
> >
> >   With `USE_NSEC`
> >   compile-time option, `st_mtim.tv_nsec` and `st_ctim.tv_nsec`
> >   members are also compared. On Linux, this is not enabled by default
> >   because in-core timestamps can have finer granularity than
> >   on-disk timestamps, resulting in meaningless changes when an
> >   inode is evicted from the inode cache.  See commit 8ce13b0
> >   of git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> >   ([PATCH] Sync in core time granularity with filesystems,
> >   2005-01-04). This patch is included in kernel 2.6.11 and newer, but
> >   only fixes the issue for file systems with exactly 1 ns or 1 s
> >   resolution. Other file systems are still broken in current Linux
> >   kernels (e.g. CEPH, CIFS, NTFS, UDF), see
> >   https://lore.kernel.org/lkml/5577240D.7020309@gmail.com/
> >
> > That's the most succinct description of the problem I've seen, but I
> > have no idea how widely it still applies. Kernel 2.6.11 is quite old
> > now, but I could believe that other filesystems (especially network
> > ones) still exhibit the issue.
> >
> > 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.
>
> > 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.
>
> Patrick
This bit addressed more down-thread, so I'll reply there.

To summarize: If we're all leaning in the direction of a run-time flag instead, I can noodle in that direction. That certainly involves a bit more surgery than just giving Meson access to the option, but the dynamism may be nice. I'm not too sure how we'd write a test case for it, though.

D. Ben KnobleJul 3, 2026, 15:46 UTC in reply to Jeff King on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

FWIW…
On Sun, Jun 28, 2026 at 4:18 AM Jeff King <peff@peff.net> wrote:
Show 35 quoted lines
>
> On Mon, Jun 22, 2026 at 10:13:21AM +0200, Patrick Steinhardt wrote:
>
> > > 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 also get 9 digits of fractional precision (nanoseconds) with the same answers across dropped cache on my XFS system.

Show 17 quoted lines
> 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?
>
> > > 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.
>
> -Peff
D. Ben KnobleJul 3, 2026, 15:46 UTC in reply to Jeff King on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Tue, Jun 30, 2026 at 1:43 AM Jeff King <peff@peff.net> wrote:
Show 35 quoted lines
>
> On Mon, Jun 29, 2026 at 08:08:42AM +0200, Patrick Steinhardt wrote:
>
> > > 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.
>
> Yeah, this came up earlier in the thread. It would be nice if we could
> set it automatically, but I'm not sure we have a good way of testing a
> particular filesystem. I think the sequence is:
>
>   1. stat() a file, getting nanoseconds
>
>   2. somehow flush the kernel's in-core inode cache
>
>   3. stat() it again and compare
>
> Step 2 is the tricky part. ;) It's not only not portable, but probably
> something that would annoy users if we did it for every repo creation.
>
> It would also be nice if we could actually verify that the sequence
> above _does_ show the problem. I was not able to come up with a failing
> instance on my modern Linux machine (even going as far as unmounting and
> re-mounting for step 2).

Brian suggested in a sibling message that a statfs call could be used for "known-good" file system types, IIUC.

Show 5 quoted lines
> But I do agree in general that it should be a config flag and not a
> build option. Run-time flags are more friendly to users when there is no
> good reason to avoid them.
>
> -Peff

If we're all leaning in the direction of a run-time flag instead, I can noodle in that direction. That certainly involves a bit more surgery than just giving Meson access to the option, but the dynamism may be nice. I'm not too sure how we'd write a test case for it, though.

Patrick SteinhardtJul 6, 2026, 06:43 UTC in reply to D. Ben Knoble on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Fri, Jul 03, 2026 at 11:46:14AM -0400, D. Ben Knoble wrote:
Show 18 quoted lines
> [with apologies for the delay; I wasn't paying attention to "What's
> cooking" to notice that this was waiting on my response.]
> 
> On Mon, Jun 22, 2026 at 4:13 AM Patrick Steinhardt <ps@pks.im> wrote:
> > On Sun, Jun 21, 2026 at 01:49:34PM -0400, Jeff King wrote:
> > > 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.
> 
> This bit addressed more down-thread, so I'll reply there.
> 
> To summarize: If we're all leaning in the direction of a run-time flag
> instead, I can noodle in that direction. That certainly involves a bit
> more surgery than just giving Meson access to the option, but the
> dynamism may be nice. I'm not too sure how we'd write a test case for
> it, though.

I don't think we'd necessarily need a way to detect this. Our current build default is to have this disabled, so I'd keep it this way, but automatically compile nsec-support into Git if available. And then we provide a way for users to opt-in to the new behaviour via the config.

An automated test would of course be nice to have so that we know to enable this in cases where we can determine that it works. But with the above we'd already make the feature more accessible than it currently is, because I'd expect that most distros simply don't enable the build toggle at all.

Patrick
Jeff KingJul 7, 2026, 04:38 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

On Mon, Jul 06, 2026 at 08:43:43AM +0200, Patrick Steinhardt wrote:
Show 10 quoted lines
> > To summarize: If we're all leaning in the direction of a run-time flag
> > instead, I can noodle in that direction. That certainly involves a bit
> > more surgery than just giving Meson access to the option, but the
> > dynamism may be nice. I'm not too sure how we'd write a test case for
> > it, though.
> 
> I don't think we'd necessarily need a way to detect this. Our current
> build default is to have this disabled, so I'd keep it this way, but
> automatically compile nsec-support into Git if available. And then we
> provide a way for users to opt-in to the new behaviour via the config.

Yeah, agreed. Even if we eventually auto-detect, the first step is adding the config at all. And then we can decide whether to stop there or not.

I'm agnostic on whether we add USE_NSEC to meson in the meantime, if it might eventually be ripped out of the Makefile. We _could_ retain USE_NSEC to change the unconfigured default for a given build, but I'd be inclined to just remove it entirely once the runtime config is available.

-Peff
Junio C HamanoJul 11, 2026, 22:46 UTC in reply to Patrick Steinhardt on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

Patrick Steinhardt <ps@pks.im> writes:
Show 10 quoted lines
> I don't think we'd necessarily need a way to detect this. Our current
> build default is to have this disabled, so I'd keep it this way, but
> automatically compile nsec-support into Git if available. And then we
> provide a way for users to opt-in to the new behaviour via the config.
>
> An automated test would of course be nice to have so that we know to
> enable this in cases where we can determine that it works. But with the
> above we'd already make the feature more accessible than it currently
> is, because I'd expect that most distros simply don't enable the build
> toggle at all.

In any case, the discussion tells me that if we were to pursue this topic further, it would not primarily be about adding the build knob to meson.build file, but rather a bit more involved to affect the product for everybody regardless of the build framework used.

So I think it is safe for me discard this topic from my tree for now, with an invitation to resurrect it as a topic with shifted focus.

Thanks.
Ben KnobleJul 13, 2026, 22:17 UTC in reply to Junio C Hamano on lore

Re: [PATCH] meson: wire up USE_NSEC build knob

Show 25 quoted lines
> Le 11 juil. 2026 à 18:46, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> Patrick Steinhardt <ps@pks.im> writes:
> 
>> I don't think we'd necessarily need a way to detect this. Our current
>> build default is to have this disabled, so I'd keep it this way, but
>> automatically compile nsec-support into Git if available. And then we
>> provide a way for users to opt-in to the new behaviour via the config.
>> 
>> An automated test would of course be nice to have so that we know to
>> enable this in cases where we can determine that it works. But with the
>> above we'd already make the feature more accessible than it currently
>> is, because I'd expect that most distros simply don't enable the build
>> toggle at all.
> 
> In any case, the discussion tells me that if we were to pursue this
> topic further, it would not primarily be about adding the build knob
> to meson.build file, but rather a bit more involved to affect the
> product for everybody regardless of the build framework used.
> 
> So I think it is safe for me discard this topic from my tree for
> now, with an invitation to resurrect it as a topic with shifted
> focus.
> 
> Thanks.
Yep, I’d been meaning to send a « please discard » message per the new guidelines ;) been on vacation.

Back to recent threads