I'd very much like to haveany approach towards identifying local token expiration.
Alternative idea:

• the username is (for the generic provider, at the moment) basically unused (fixed value).
• we can change the stored value toOAUTH_USER@<expiration>.

The last approach changing the API for the storage format (#1464) is now stale for almost a year.
Neither suggestions here would need additional code to be touched.

Theusername approach is likely evenwaaayyy more compact.
For fully transparent handling of Git credential flow usingstore, thefull username must be retained for theauth_token credential.
Due to limitations of Git using a BasicAuth header, a colon isnot a valid separator.

Some major caveat found while trying to prototype a "username@expiration" approach:
API mayonly returnexpires_in for the newaccess_token, not an updaterefresh_token!

Some storage back ends may also be thrown off by the changing username…

Relative time in protocol additionally indicates this is to be used as a transient element.
Committing that value to permanent storage (after calculating an absolute date) feels like a data flow violation.

For now I'd definitely favor using structured token detection (transparent, backward-compatible, non-intrusive).

@mjcheetham@mpysson can you please take a look at this change? It's already been iterated upon.

@mjcheetham@mpysson there've been no changes in this project for 5 months. Can I co-maintain it? Not sure if I can do it long term but I promise to go through the currently open pull requests at the very least. Better than nothing.

any updates on this push?

any updates on this push?

@itsjustnickdev cautiously: yes. I opened#2059.

However, during the extended time of ownership limbo, Git Credential Manager's release process has withered to the point where no releases can be made as of time of writing (notarizing, for example, is broken, yet it is required for Git Credential Manager to work on macOS).

Therefore, the primary concern right now is to get that release process into a healthy shape.

If you want to look into#2059 in the meantime, that would be really cool, of course!

@mjcheetham replaced handling of JWT with ageneric StructuredToken placeholder.

This should make expanding support (or replace implementation) fairly easily later on.
Kept theminimalist JWT extraction approach (fancy 3-liner plus boilerplate) for now.