I am not able to reproduce this with current git-annex.

But, I was able to reproduce it with git-annex 10.20251029.

I have not bisected to find the fix, but will close this.

git-annex push won't always trigger this problem because often it has things to git push to the server before sending content. A more reliable way is to use git-annex copy --to.

git-annex push is talking to git-annex p2phttp which is on a Forgejo-aneksajo server.

In this case, the server responds with HTTP 401, and I have verified that response does not include the www-authenticate header.

So, git-annex's code to send that header on to git-credential seems fine, and this needs to be fixed in either p2phttp or Forgejo-aneksajo to make the header be sent. I suspect it will need to be done in Forgejo-aneksajo.

The wwwauth field is the relevant one.

There was a past bug about a very similar problem: https://git-annex.branchable.com/bugs/__96__git_annex_push__96___does_not_use_git-credential-oauth/

32fac0b103db1982b748f15def825e1490d34f50 was supposed to fix that, by passing the www-authenticate http header in to git credential.

This bug must be a case where that doesn't happen.

@mih told me the url privately. (There is only 1.)

It is indeed a host which when passed to git-credential-oauth get it decides not to do anything.

But, git push to the same url uses git-credential-oauth get and it does do oauth.

Dumping what git sends to it, there are additional fields beyond what git-annex sends:

capability[]=authtype
capability[]=state
protocol=https
host=<obscured>
wwwauth[]=Basic realm="Gitea"

In your bug report I noticed that the password prompt is for "https://oauth2@<host>" but when you git push it's to "https://<host>/<repo>.git". I'm not clear on if these were really different urls or if it was a mistake in your sanitization.

If there are different urls, git-credential-oauth could have acted on one and not on the other. Although I don't understand why running git pull would then cache a credential that would be used on a different url.

Assuming you're using git-credential-oauth from eg the Debian package of that name, here's an example of it not acting on an url:

joey@darkstar:~/tmp/x>(echo 'protocol=https'; echo 'host=example.com'; echo 'username=oauth2') | git-credential-oauth get
joey@darkstar:~/tmp/x>

Running it the same way with github.com doesn't behave that way:

joey@darkstar:~/tmp/x>(echo 'protocol=https'; echo 'host=github.com'; echo 'username=oauth2') | git-credential-oauth get
Please complete authentication in your browser...

This behavior is not network dependent. In fact, git-credential-oauth has a pile of special casing for different hosts and different servers, including a looksLikeForgejo case. If it does not recognize the server name, it doesn't do anything without further configuration.

The "Password for" prompt comes from git-credential, not git-annex.

I was able to reproduce that behavior using a git-credential-foo "helper" which just exits successfully but does not output any credentials. With the git config adjusted to use that (as well as cache), git runs it but then falls back to the password prompt:

joey@darkstar:~/tmp/a1>GIT_TRACE=2 git push foo
12:08:19.869469 git.c:502               trace: built-in: git push foo
12:08:19.869942 run-command.c:673       trace: run_command: GIT_DIR=.git git remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:19.869965 run-command.c:765       trace: start_command: /usr/lib/git-core/git remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:19.873067 git.c:808               trace: exec: git-remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:19.873107 run-command.c:673       trace: run_command: git-remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:19.873121 run-command.c:765       trace: start_command: /usr/lib/git-core/git-remote-https foo https://github.com/joeyh/gitannexbuilder
12:08:20.549858 run-command.c:673       trace: run_command: 'git credential-cache get'
12:08:20.549927 run-command.c:765       trace: start_command: /bin/sh -c 'git credential-cache get' 'git credential-cache get'
12:08:20.555753 git.c:502               trace: built-in: git credential-cache get
12:08:20.556612 run-command.c:673       trace: run_command: 'git credential-foo get'
12:08:20.556635 run-command.c:765       trace: start_command: /bin/sh -c 'git credential-foo get' 'git credential-foo get'
12:08:20.561465 git.c:808               trace: exec: git-credential-foo get
12:08:20.561506 run-command.c:673       trace: run_command: git-credential-foo get
12:08:20.561530 run-command.c:765       trace: start_command: /home/joey/bin/git-credential-foo get
Username for 'https://github.com':

So it seems likely that git-credential-oauth is just choosing not to do anything when git-annex runs it, and then git is falling back like that.

Why it would choose to do that I don't know, but I suppose it could be a difference in that is sent to it on stdin when called by git-annex vs by git.

At the risk of introducing a second red herring, this seems similar to git annex checkpresentkey removes git credentials. But I don't think the same, because here git-annex push works after git push has cached a credential, so git-annex is apparently not removing the cached credential.

Could you link to the forgejo-aneksajo issue that is/was being dealt with?

This would still be worth doing despite git-annex supporting BLAKE3 now. XXHASH is even faster, due to not needing to do the work to be cryptographically secure.