Re: Fwd: [Bug] `credential fill` prints incomplete bearer credential

[Junio C Hamano <gitster@pobox.com>]

"brian m. carlson" <sandals@crustytoothpaste.net> 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.