From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Bo Anderson <mail@boanderson.me>,
Koji Nakamaru via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] osxkeychain: lock for exclusive execution
Date: Fri, 10 May 2024 13:40:29 -0700 [thread overview]
Message-ID: <xmqqh6f54czm.fsf@gitster.g> (raw)
In-Reply-To: <20240510200114.GC1954863@coredump.intra.peff.net> (Jeff King's message of "Fri, 10 May 2024 16:01:14 -0400")
Jeff King <peff@peff.net> writes:
> - we could remember _which_ helper we got the credential from, and
> avoid invoking it again.
>
> - we could record a bit saying that the credential came from a helper,
> and then feed that back to helpers when storing. So osxkeychain
> could then decide not to store it.
>
> Both of those solve the repeated stores, but still let credentials
> populate across helpers (which I still think is a questionable thing to
> do by default, per the discussion in that thread, but is the very thing
> that some people rely on).
Would "refreshing the last-time-used record" a valid use case for
the behaviour that feeds the successful one back to where the
credential came from? Such a helper could instead log the last-time
the credential was asked for, and assume that the lack of an explicit
"reject" call signals that the use of the value it returned earlier
was auccessfully used, but it is a less obvious way to implement
such a "this hasn't been successfully used for a long time, perhaps
we should expire/ask again/do something else?" logic.
next prev parent reply other threads:[~2024-05-10 20:40 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 8:07 [PATCH] osxkeychain: lock for exclusive execution Koji Nakamaru via GitGitGadget
2024-05-10 15:02 ` Bo Anderson
2024-05-10 20:01 ` Jeff King
2024-05-10 20:33 ` brian m. carlson
2024-05-10 22:07 ` Jeff King
2024-05-10 23:12 ` brian m. carlson
2024-05-10 20:40 ` Junio C Hamano [this message]
2024-05-10 22:09 ` Jeff King
2024-05-10 22:50 ` Junio C Hamano
[not found] ` <C0C8F71D-2A01-4C31-9EB6-AB31FA17C3AB@boanderson.me>
2024-05-10 18:26 ` Koji Nakamaru
2024-05-11 11:55 ` [PATCH v2 0/2] " Koji Nakamaru via GitGitGadget
2024-05-11 11:55 ` [PATCH v2 1/2] " Koji Nakamaru via GitGitGadget
2024-05-12 4:09 ` Junio C Hamano
2024-05-12 6:47 ` Koji Nakamaru
2024-05-11 11:55 ` [PATCH v2 2/2] osxkeychain: state[] seen=1 to skip unnecessary store operations Koji Nakamaru via GitGitGadget
2024-05-12 4:09 ` Junio C Hamano
2024-05-12 7:05 ` Koji Nakamaru
2024-05-15 19:21 ` [PATCH v3 0/2] osxkeychain: lock for exclusive execution Koji Nakamaru via GitGitGadget
2024-05-15 19:21 ` [PATCH v3 1/2] osxkeychain: exclusive lock to serialize execution of operations Koji Nakamaru via GitGitGadget
2024-05-15 19:21 ` [PATCH v3 2/2] osxkeychain: state to skip unnecessary store operations Koji Nakamaru via GitGitGadget
2024-05-15 19:41 ` [PATCH v3 0/2] osxkeychain: lock for exclusive execution Koji Nakamaru
-- strict thread matches above, loose matches on Subject: below --
2024-05-11 12:20 [PATCH] " Koji Nakamaru
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=xmqqh6f54czm.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=mail@boanderson.me \
--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.
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 NNTP newsgroup(s).