"brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > On 2024-12-18 at 20:42:31, M Hickford wrote: >> Hi. Is this a bug in git version 2.47.1? Or am I using it incorrectly? >> >> # erase existing example.com credentials >> printf "host=example.com\nprotocol=https\n" | git -c credential.helper= -c credential.helper=cache credential reject >> # store bearer token with expiry in far future in credential-cache >> printf "host=example.com\nprotocol=https\nauthtype=bearer\ncredential=letmein\npassword_expiry_utc=2147483640\n" >> | git credential-cache store >> # try to retrieve credential >> printf "host=example.com\nprotocol=https\n" | git -c credential.helper= -c credential.helper=cache credential fill >> >> Expected output (complete credential): >> >> protocol=https >> host=example.com >> authtype=bearer >> credential=letmein >> password_expiry_utc=2147483640 >> >> Actual output (incomplete credential, no prompt for username or password): >> >> protocol=https >> host=example.com >> password_expiry_utc=2147483640 > > This is expected. Every request to a credential helper should include > all of the capabilities that the caller supports on input, and the > credential helper will always emit those on output. `git credential`, > however, will only emit the capabilities that were actually supported, > so that general callers (including Git LFS) can determine the actual > set of supported capabilities. > ... The original report did - run "git credential reject" to clear - run "git credential-cache store"!! - run "git credential fill" to check which looked curious. Am I correct to understand that if the second step is replaced with "git credential approve" (which calls "credential-cache store" internally), the right thing happens and necessary capabilities are passed? Thanks.
