Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Patrick Steinhardt <ps@pks.im>
Cc: "D. Ben Knoble" <ben.knoble+github@gmail.com>,
	git@vger.kernel.org,
	"brian m . carlson" <sandals@crustytoothpaste.net>,
	Junio C Hamano <gitster@pobox.com>,
	Ramsay Jones <ramsay@ramsayjones.plus.com>
Subject: Re: [PATCH] meson: wire up USE_NSEC build knob
Date: Tue, 30 Jun 2026 01:43:14 -0400	[thread overview]
Message-ID: <20260630054314.GD2495216@coredump.intra.peff.net> (raw)
In-Reply-To: <akIL6oJgUv8J8SB2@pks.im>

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

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

      parent reply	other threads:[~2026-06-30  5:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-20 16:00 [PATCH] meson: wire up USE_NSEC build knob D. Ben Knoble
2026-06-21  1:01 ` Junio C Hamano
2026-06-21 16:41   ` D. Ben Knoble
2026-06-22  8:13   ` Patrick Steinhardt
2026-06-21 17:49 ` Jeff King
2026-06-22  8:13   ` Patrick Steinhardt
2026-06-28  8:18     ` Jeff King
2026-06-28  8:48       ` Jeff King
2026-06-29  0:23         ` brian m. carlson
2026-06-29  6:08       ` Patrick Steinhardt
2026-06-29 21:38         ` Junio C Hamano
2026-06-30  5:43         ` Jeff King [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260630054314.GD2495216@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=ben.knoble+github@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ps@pks.im \
    --cc=ramsay@ramsayjones.plus.com \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox