All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: "D. Ben Knoble" <ben.knoble@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, Tian Yuchen <cat@malon.dev>,
	Todd Zullinger <tmz@pobox.com>,
	Olamide Caleb Bello <belkid98@gmail.com>
Subject: Re: [PATCH 3/3] core: convert build-time USE_NSEC into runtime core.useNanosec
Date: Mon, 10 Aug 2026 14:44:04 +0200	[thread overview]
Message-ID: <annHlFwu4NKwmcLr@pks.im> (raw)
In-Reply-To: <CALnO6CBm4g27mWBvD9m6yL0e5YZu3M9_zcUeLZk7QwTgnxMLQA@mail.gmail.com>

On Mon, Aug 10, 2026 at 08:27:51AM -0400, D. Ben Knoble wrote:
[snip]
> Back down to being on-par with original code. So that's good. The next
> version will include some variant that reads a struct member instead
> of going through repo_config_get_bool().
> 
> But which? Reading the private_ member is obviously wrong; I suppose
> I'm supposed to use repo_config_values() there. Or, rework the series
> to put this member in repo_settings. I think I originally assumed that
> struct is for things that are settings that aren't configured by
> git-config, but… now I'm not sure. Looking at prepare_repo_settings()
> shows lots of repo_cfg_*() calls. So I think I see how to adapt to
> using repo_settings,
> 
> Patrick, Junio, and Tian had a brief discussion in
> <anlmwaEtwcCPse1N@pks.im> about the split creating confusion. I don't
> really want to wait for it to settle to land this change, but we might
> want to work together on identifying the best path forward for
> core.useNanosec :)
> 
> I don't suppose it really matters to me which struct I put the member
> in. As I said, v2 will definitely fix the hot path lookup here. Just a
> matter of input on which struct we want to use this time, I guess.

I think `repo_config_values()` is the modern variant that we're slowly
migrating stuff into. But that struct only works with `the_repository`,
so the question is whether we ever use "core.useNsec" for a different
repository. My hunch would be yes, for example when recusing into
submodules, but I'm not sure.

Patrick

  reply	other threads:[~2026-08-10 12:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-07 11:56 [PATCH 0/3] Convert USE_NSEC to runtime config D. Ben Knoble
2026-08-07 11:56 ` [PATCH 1/3] meson: expose knob for xmlto relative links in manuals D. Ben Knoble
2026-08-10 12:50   ` Patrick Steinhardt
2026-08-07 11:56 ` [PATCH 2/3] environment: align repo_config_values_init with struct declaration D. Ben Knoble
2026-08-07 11:56 ` [PATCH 3/3] core: convert build-time USE_NSEC into runtime core.useNanosec D. Ben Knoble
2026-08-07 21:17   ` Junio C Hamano
2026-08-08 16:31     ` SZEDER Gábor
2026-08-10 12:27       ` D. Ben Knoble
2026-08-10 12:27     ` D. Ben Knoble
2026-08-10 12:44       ` Patrick Steinhardt [this message]
2026-08-11 16:26         ` Ben Knoble
2026-08-10 12:50   ` Patrick Steinhardt

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=annHlFwu4NKwmcLr@pks.im \
    --to=ps@pks.im \
    --cc=belkid98@gmail.com \
    --cc=ben.knoble@gmail.com \
    --cc=cat@malon.dev \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tmz@pobox.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.