Re: [PATCH v5 3/3] core: convert build-time USE_NSEC into runtime core.useNanosec

>
> On Sun, Aug 30, 2026 at 08:27:13PM -0400, D. Ben Knoble wrote:
> > On Sun, Aug 30, 2026 at 5:15 PM Junio C Hamano <gitster@pobox.com> wrote:
> > >
> > > "D. Ben Knoble" <ben.knoble@gmail.com> writes:
> > >
> > > > +             /* nanosecond timestamped files can also be racy! */
> > > > +             (repo_config_values(istate->repo)->use_nanosec
> > > > +              ? (istate->timestamp.sec < sd->sd_mtime.sec ||
> > > > +                 (istate->timestamp.sec == sd->sd_mtime.sec &&
> > > > +                  istate->timestamp.nsec <= sd->sd_mtime.nsec))
> > > > +              : istate->timestamp.sec <= sd->sd_mtime.sec));
> > > >  }
> > >
> > > Currently this is probably fine, but the use of repo_config_values()
> > > here means that the order in which we can transition/libify two
> > > unrelated things are forced on us:
> > >
> > >  * We'd first need to make sure repo_config_values() can work on an
> > >    instance of repository that is not the_repository,
> > >
> > >  * And until the above happens, we cannot do a --recurse-submodule
> > >    option that loads the index in a submodule and operate on it in
> > >    the same process (e.g., "git diff --resurse-submodules"),
> > >    because immediately at this step, istate taken from a submodule
> > >    would have its .repo member pointing at something that is not
> > >    the_repository and we will hit a BUG().
> > >
> > > And after writing all of the above, I realized that I am mostly
> > > repeating what Patric already said in the upstream, e.g.,
> > >
> > >     https://lore.kernel.org/git/an720tZnot07HYiK@pks.im/
> >
> > Yep---just so I'm clear, we don't currently have such an option,
> > right? I mean, there is no --recurse-submodules for git-diff(1), and I
> > tweaked t4060 to run "git -c core.useNanosec=true diff
> > --submodule=diff" without any issue.
>
> I do have a patch series coming up where we start to rely more on
> sub-repositories when recursing. The motivation behind that series is
> that it allows us to get rid of registering submodule object databases
> with the main ODB. But I just double-checked, and your series luckily
> doesn't break it.

> > I would happily prove that at least none of our existing tests fail
> > with core.useNanosec=true, but I'm not really sure how to shove
> > configuration into every test invocation of git. Even if we could, I'm
> > not sure we necessarily want to add another CI job for that (though
> > that's a separate matter).
> >
> > In particular, (among others) I have not received any concrete comments for
> >
> > > 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.
> >
> > so if there's at least a way to exercise this path on all the tests on
> > my system (which should support it), that would probably be a good
> > thing.
>
> Yeah, I simply don't have a good answer here. It's messy, and I'm not a
> fan of the current direction of `repo_config_values()` because nobody
> has yet stepped up to untangle it from `the_repository`. I gave it a
> quick shot at one point in time, but the result was messy at best
> because of how we populate it via `repo_config(git_default_config)`.

> In any case, if we see that your changes interact badly with some edge
> cases that we don't currently have on our radar then we can still
> refactor the series and move the value into `struct repo_settings`
> instead, as that structure works alright with different repositories.
>
> Thanks!
>
> Patrick