Why not use git-credential-cache?

[znewman01]

Git has a credential cache of its own that looks very similar to the gitsign-credential-cache.

I assume there's a good reason not to use it; can we add that to the README?

[wlynch]

They are very similar! (I based most of what we did on it)

Most of it comes from we weren't (and in some aspects still aren't) sure what we wanted the cache to look like. It was easy enough to write an in-memory cache that we had control over.

The existing git-credential-cache and credential helpers are primarily intended for getting credentials for remote operations. If we reused the same cache instance we'd have to be very careful to avoid accidentally let git try to use signing creds as remote passwords.
We could probably spawn the git-credential-cache to a different path and encode the keypair as a "password" if we wanted to. The main concern here is it we would need to be careful and try and make it difficult for users to misconfigure it - i.e. if we have a similar setup as we do now where users need to specify the socket path, it would be really easy to point it to the remote cache since that's what the cache wants to default to.

So tl;dr the main benefit is it prevents co-mingling of push/pull and signing creds, but we could use it if we wanted to.

[hickford]

FYI Git for Windows ships without git-credential-cache (though it is possible to build on Windows 10)

credential-cache unavailable; no unix socket support