git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] osxkeychain: lock for exclusive execution

From
Jeff King <peff@peff.net>
Date
May 10, 2024, 20:01 UTC
Message-ID
<20240510200114.GC1954863@coredump.intra.peff.net>
In-Reply-To
<D7A8539F-E33C-44F3-A7BF-5F5D4A26F2A4@boanderson.me>
On Fri, May 10, 2024 at 04:02:03PM +0100, Bo Anderson wrote:
Show 5 quoted lines
> A broader Git-wide question that you perhaps don’t know the answer to
> but someone else here might do is: why are we spamming updates to the
> credential helper? Every parallel fetch instance performing a store
> operation on the same host seems unexpected to me, particularly if
> there’s no actual changes.

The short answer is that Git always passes a credential which has been used successfully to the helpers to record (if they want to). That's how stuff gets stored in the first place. And those parallel fetches have no knowledge of what the other ones are doing, so they all try to store.

But the more interesting question is: why do we tell helpers to store a credential that we got from helpers in the first place? The behavior is mostly an artifact of how the original implementation behaved, as it did not record the source of the credential.

And I think there are several problems with that, besides inefficiency and locking. See this old patch, which fixes it by remembering when a credential came from a helper:

  https://lore.kernel.org/git/20120407033417.GA13914@sigill.intra.peff.net/

But we didn't merge it because some people rely on the behavior of helpers feeding back to themselves. I outlined some solutions there, but it would definitely be a change in behavior that people would have to adapt to.

Some possible alternatives:
  - 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).

-Peff
Previous: Bo AndersonNext: brian m. carlson
Message 3 of 21 in “osxkeychain: lock for exclusive execution”
  1. osxkeychain: lock for exclusive executionKoji Nakamaru via GitGitGadget, May 10, 2024
  2. Bo AndersonMay 10, 2024
  3. Jeff KingMay 10, 2024
  4. brian m. carlsonMay 10, 2024
  5. Jeff KingMay 10, 2024
  6. brian m. carlsonMay 10, 2024
  7. Junio C HamanoMay 10, 2024
  8. Jeff KingMay 10, 2024
  9. Junio C HamanoMay 10, 2024
  10. 0/2 osxkeychain: lock for exclusive executionKoji Nakamaru via GitGitGadget, May 11, 2024
  11. 1/2 osxkeychain: lock for exclusive executionKoji Nakamaru via GitGitGadget, May 11, 2024
  12. Junio C HamanoMay 12, 2024
  13. Koji NakamaruMay 12, 2024
  14. 2/2 osxkeychain: state[] seen=1 to skip unnecessary store operationsKoji Nakamaru via GitGitGadget, May 11, 2024
  15. Junio C HamanoMay 12, 2024
  16. Koji NakamaruMay 12, 2024
  17. 0/2 osxkeychain: lock for exclusive executionKoji Nakamaru via GitGitGadget, May 15, 2024
  18. 1/2 osxkeychain: exclusive lock to serialize execution of operationsKoji Nakamaru via GitGitGadget, May 15, 2024
  19. 2/2 osxkeychain: state to skip unnecessary store operationsKoji Nakamaru via GitGitGadget, May 15, 2024
  20. Koji NakamaruMay 15, 2024
  21. Koji NakamaruMay 10, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.