From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: git@vger.kernel.org
Cc: "Jeff King" <peff@peff.net>, "Junio C Hamano" <gitster@pobox.com>,
"Max Gautier" <max.gautier@redhat.com>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: [PATCH 0/2] gpg-interface: cleanup + convert low hanging fruit to configset API
Date: Thu, 9 Feb 2023 15:35:04 +0100 [thread overview]
Message-ID: <cover-0.2-00000000000-20230209T142225Z-avarab@gmail.com> (raw)
In-Reply-To: <+TqEM21o+3TGx6D@coredump.intra.peff.net>
On Thu, Feb 09 2023, Jeff King wrote:
> If the gpg code used git_config_get_string(), etc, then they could just
> access each key on demand (efficiently, from an internal hash table),
> which reduces the risk of "oops, we forgot to initialize the config
> here". It does probably mean restructuring the code a little, though
> (since you'd often have an accessor function to get "foo.bar" rather
> than assuming "foo.bar" was parsed into an enum already, etc). That may
> not be worth the effort (and risk of regression) to convert.
I'd already played around with that a bit as part of reviewing Junio's
change, this goes on top of that.
I found that continuing this conversion was getting harder, but these
3 cases really were trivial cases where we're just reading a variable
globally, and then proceeding to use it in one specific place.
Out of the remaining ones gpg.program et all looked easiest, but I
didn't continue with it.
For anyone interested think it would be best to continue by converting
the remaining bits by having commit, tag etc. set up some "struct
gpg", so that when they could directly instruct it ot do its config
reading before parse_options(). The remaining complexity is mainly
with the file-global & having to juggle in what order we read & set
what.
FWIW when poking at this I found that we have fairly robust testing
support for this area, but it could be better, but it's good enough to
spot that if we stop reading these we'll fail tests.
But e.g. for the "gpg.program" we've got tests that'll fail if the
"gpg" program variable isn't read, but not for the "ssh" variable, but
as they'll both share the same/similar reader code any future
migration should spot any glaring bugs, just possibly not subtle ones.
Branch & passing[1] CI at:
https://github.com/avar/git/tree/avar/gpg-lazy-init-configset
1. Well, passing except for the general current Windows CI dumpster
fire on topics based off current "master".
Ævar Arnfjörð Bjarmason (2):
{am,commit-tree,verify-{commit,tag}}: refactor away config wrapper
gpg-interface.c: lazily get GPG config variables on demand
builtin/am.c | 7 +----
builtin/commit-tree.c | 7 +----
builtin/verify-commit.c | 7 +----
builtin/verify-tag.c | 7 +----
gpg-interface.c | 66 ++++++++++++++++-------------------------
5 files changed, 29 insertions(+), 65 deletions(-)
--
2.39.1.1475.gc2542cdc5ef
next parent reply other threads:[~2023-02-09 14:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <+TqEM21o+3TGx6D@coredump.intra.peff.net>
2023-02-09 14:35 ` Ævar Arnfjörð Bjarmason [this message]
2023-02-09 14:35 ` [PATCH 1/2] {am,commit-tree,verify-{commit,tag}}: refactor away config wrapper Ævar Arnfjörð Bjarmason
2023-02-09 14:35 ` [PATCH 2/2] gpg-interface.c: lazily get GPG config variables on demand Ævar Arnfjörð Bjarmason
2023-02-09 21:27 ` [PATCH 0/2] gpg-interface: cleanup + convert low hanging fruit to configset API Junio C Hamano
2023-02-10 10:29 ` Ævar Arnfjörð Bjarmason
2023-02-10 19:02 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cover-0.2-00000000000-20230209T142225Z-avarab@gmail.com \
--to=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=max.gautier@redhat.com \
--cc=peff@peff.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).