I have updated export and import appendix to document this new interface. I decided to not try to support a combined exporttree=yes and importtree=yes for external special remotes because noone has ever stepped forward to implement an external special remote that can safely do that. I know it will be much easier and safer to implement importtree only external special remotes.

The external special remote interface for this still needs to be implemented. Work has begun in the importonly_external branch.)

This is now possible to implement, since git-annex has an interface for importtree-only special remotes.

To list, it could avoid checksums and use:

rsync -a --dry-run --out-format='%l|%M|%L|%n' $repo empty-directory

The '%l' field is the file size and combined with the '%M' field's mtime, would constitute the ContentIdentifier. Rsync uses a hardcoded mtime format like "2026/07/13-12:49:50" which git-annex could parse and convert to seconds-from-epoch to save a little bit of space.

The '%L' field will be non-empty when it's a symlink, and those would be skipped.

The '%n' field is the filename, which may be prefixed with a common top-level directory or module name. Note that rsync escapes some characters, eg \#012 is \n.

Size+mtime as a ContentIdentifier is good enough, it only would prevent git-annex from noticing and updating the import when:

1. Two files with the same size and mtime got swapped with one-another.
2. A file is modified in place without updating the mtime or changing its size.

This is implemented at the haskell level. But the external special remote protocol doesn't support it yet.

I think it would actually be better to modify Types.Remote and add a new interface specifically for this, than to try to jam it into an existing interface it was not designed for.

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"