Topic name: dk/use-nsec-runtime (applied) Topic summary: Expose USE_NSEC as a runtime configuration, since build-time is too early for distributing Git [1]. As a result, common index-related options, like git-diff, are less likely to hit "racy git" problems on supported filesystems. [1]: https://git.github.io/rev_news/2026/07/31/edition-137/ Built on master (2c78326f81 (The 11th batch, 2026年08月05日)). Changes in v5: - improve message flow in patch 2 Junio: my apologies. I missed that the "What's cooking" changed from "Needs review" (#10) to "expecting a small (hopefully final) reroll" (#11, #12), since I was expecting to see Patrick's review. This just tweaks the commit message as you suggested. Changes in v4: - fix message typo - change #ifdef strategy: only ignore the config variable. Otherwise, use the use_nanosec member unconditionally. Also clarify that config might be ignore depending on build options in the docs. - mention potential platform unsafety directly in config doc in addition to the link to Racy Git Changes in v3: - #ifdef out use_nanosec when NO_NSEC is requested As I have heard no comments about the "Todo" lines below, which perhaps could more clearly be marked "RFC"/"RFH", I've added this line to call them out ;) and renamed them "Comments welcome" Changes in v2: - move Best-viewed-with trailer into message body as descriptive text. - read core.useNanosec through struct repo instead of parsing config strings. The test suite passes locally this way, though that skipped 151 tests. - CI run: https://github.com/benknoble/git/actions/runs/31701945211 Original cover letter: Hi all, this series follows up on the previous racy Git/USE_NSEC conversations. - The first patch is a mostly-unrelated documentation fix for Meson, but it came out of something I spotted while reviewing the outputs of the final (main) patch. - The second patch is a preliminary no-op reorganization of repo_config_values_init. - The third patch is the meat, converting USE_NSEC into core.useNanosec. There is a small textual and semantic conflict with 'ty/repo-config-cleanups' in 'seen', since that branch removes the comments in 'struct repo_config_values' which this series adds to. (The semantic conflict is that, if we drop those comments, we should probably not add them to repo_config_values_init like I do in patch 2.) Comments welcome: I haven't touched any tests; I saw a bunch of hits for "git grep racy t" but wasn't sure how to fit this particular change in, especially since it won't be equally valid on all systems? Advice welcome. Comments welcome: I wonder if "useNanosec" paints us into too much of a corner; that is (slightly more abstractly), we are using *extended precision* in the index. Maybe the name and documentation should reflect that, so we aren't too committed to "nanoseconds"? - Some platforms could offer extended precision that is not as precise as nanoseconds - Some could offer precision _beyond_ nanoseconds idk. v1: <cover.1786103607.git.ben.knoble@xxxxxxxxx> v2: <cover.1786710807.git.ben.knoble@xxxxxxxxx> v3: <cover.1787065125.git.ben.knoble@xxxxxxxxx> v4: <cover.1787231825.git.ben.knoble@xxxxxxxxx> [1/3] meson: expose knob for xmlto relative links in manuals [2/3] environment: align repo_config_values_init with struct declaration [3/3] core: convert build-time USE_NSEC into runtime core.useNanosec Documentation/config/core.adoc | 7 +++++++ Documentation/meson.build | 7 ++++++- Documentation/technical/racy-git.adoc | 11 ++++++----- Makefile | 12 +----------- builtin/update-index.c | 2 +- compat/posix.h | 1 - configure.ac | 6 ------ environment.c | 27 ++++++++++++++++++++------- environment.h | 1 + meson_options.txt | 2 ++ read-cache.c | 15 ++++++--------- statinfo.c | 14 +++++++------- 12 files changed, 57 insertions(+), 48 deletions(-) Diff-intervalle contre v4 : 1: d612de6c2d = 1: d612de6c2d meson: expose knob for xmlto relative links in manuals 2: 5693baa992 ! 2: 12974e07d0 environment: align repo_config_values_init with struct declaration @@ Commit message environment: align repo_config_values_init with struct declaration The order of assignments in repo_config_values_init is chaotic and hard - to follow, especially when comparing with the struct definition to - ensure all members are initialized. As new members will be added in the - future, make it easier to validate changes by aligning the two. + to follow, especially with the definition of 'struct repo_config_values' + to ensure all members are initialized. As new members will be added in + the future, make it easier to validate changes by aligning the two. Refactor assignment order with no behavioral changes. 3: 0aa0e9fc17 = 3: 01cd487cd2 core: convert build-time USE_NSEC into runtime core.useNanosec base-commit: 2c78326f810173a4f3aefd8021f1e07575412481 -- 2.55.0.860.g4b6b3295ed.dirty