git-annex will filter the tree it exports to only the files that are configured to be preferred content of the remote. So you could do this:

git annex wanted android 'include=album/*'
git-annex export master --to android

See git-annex-preferred-content for details about the syntax, but basically you can extend that to as many directories as you want, separated by "or"; it will include any files in any of those directories.

How do I create a tree that contains the subfolder itself too?

Worth noting that is a general git question really, with several valid answers that don't involve git-annex at all. (One easy one is to check out a new branch, git rm everything except the subfolder, and git commit.)

And once you have such a tree stored on a git branch, you can pass that branch to git-annex export. So that's an option if you don't want to need to deal with git-annex's own filtering features.

This is a simple failure to refill a TMVar on use, so easy to fix.

T the bug has always been there since the first release of Remote.Mask. I am as surprised as you that apparently none of us tried it with multiple files before.

Reproduced. Note that {1..4} is a bashism or something and didn't work when I used it in a shell script, but seq 1 4 worked.

FWIW, I did add a note to the git-annex-export man page that git-annex expects to be the only thing writing to an exporttree=yes remote unless importtree=yes. So hopefully there will be less confused users. However, I'm doubtful that will be enough to avoid all confusion.

So, I've also made it display a warning in this situation.

This bug report appears to have been generated by an LLM.

I do not appreciate and will not engage with LLM generated content, so if you would like this bug to be looked at and fixed in a timely manner, please use your own words.

I will delete this bug as probably LLM generated if you do not do so within the next few days.

This bug has been present as long as import has supported -J, although it had code that was supposed to prevent this problem.

I've fixed it now.

Looks like there is a similar problem when importing small files, except in the doimportsmall code path it does not use download, so doesn't notice that it's downloading the same key twice. Which can leave 2 threads both writing to the same tmpfile, with possibly bad results.

I've fixed that, but only by making that case fail with the same "transfer already in progress".

Reporoduced but only once I used -J3.

This is due to the several contact_vector.npy files, which are all identical. So they have the same etag and size, and importKey generates the same temporary key for them before downloading.

A similar problem could happen when the remote supports importKeyWithContentIdentifier and that produces the same key for 2 files. I expect a -J import can fail in that situation as well.

If the web special remote supports it, does it also make sense for any other special remotes to support it? Not all of them, since that is impractical.

Since implementing this is as easy as swapping withUrlOptions to withUrlOptionsPromptingCreds, I grepped for that. The special remotes it may make sense for are bittorrent, httpalso, and external.

bittorrent I think might as well, it's very much like the web special remote.

httpalso seems like a reasonable use case too

external could for DOWNLOAD-URL -- which is already documented to support git-credential but did not. Oops. Also TRANSFER-RETRIEVE-URL, CHECKPRESENT-URL, and RETRIEVEIMPORT_URL, which I think should support it.

But external special remotes with remote.name.annex-externaltype=readonly should not; that is documented to be for cases where no authentication is needed to download.

One remote where it would not make sense is S3, which uses withUrlOptions in only when "publicurl=" is configured. Which is not supposed to involve password prompting, and if it did support git-credential, would be very confusing since that is different from the usual S3 authentication.

Also, git-annex addurl and git-annex importfeed could support git-credential, and I see no reason for them not to, once the web special remote does.

Implemented all of the above.