I've implemented re-checking of the annex.url config when remote.name.annexUrl is configured to an annex+http url.

Going to close this, but if you also need it when remote.name.annexUrl is not configured, let me know.

Would this include re-checking when remote.name.annexUrl is unset?

If that would mean checking on every use of the remote, it seems too often.

And even Debian stable now includes a new enough git-annex to support p2phttp, so the benefits of that check are more limited now to detecting server-side changes.

Given that the clone happened in the knowledge that "dumb http" was the only supported http protocol and read only, I am now questioning if such a automatic upgrade to p2phttp would really be needed, or even desirable

I think that's a good point.

So I'm inclined to make this todo only about re-checking when remote.name.annexUrl is configured to a annex+http url and it fails to connect.

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".