I have .gitattributes:

* annex.largefiles=nothing filter=annex
*.pdf annex.largefiles=anything filter=annex

and git config:

[annex]
    gitaddtoannex = true

Using git add now adds it to annex. This can be confirmed with

git annex info file.pdf

The output should show present = true at the end. If it wasn't added to annex, the output would show fatal: Not a valid object name file.pdf.

And it seems that, by default, the files are stored in the working tree in their unlocked state. So git add doesn't replace the file with a symlink unlike git annex add

I think that "annex.assistant.allowlocked" would be as confusing, like you say the user would then have to RTFM to realize that they need to use annex.addunlocked to configure it, and that it doesn't cause files to be locked by default.

To me, "treataddunlocked" is vague. Treat it as what? "allowaddunlocked" would be less vague since it does get the (full) name of the other config in there, so says it's allowing use of the other config.

I agree this is a confusing name, and I wouldn't mind changing it, but I don't think it warrants an entire release to do that. So there would be perhaps a month for people to start using the current name. If this had come up in the 2 weeks between implementation and release I would have changed it, but at this point it starts to need a backwards compatability transition to change it, and I don't know if the minor improvement of "allowaddunlocked" is worth that.

I wonder how sshfs manages stable inodes that differ from the actual ones? But if it's really reliably stable, it would be ok to use it with the directory special remote.

Extending the external special remote interface to support import would let you roll your own special remote, that could use ssh with rsync or whatever.

The current design for that tries to support both import and export, but noone has yet stepped up to the plate to try to implement a special remote that supports both safely. So I am leaning toward thinking that it would be a good idea to make the external special remote interface support only import (or export) for a given external special remote, but not both.

Then would become pretty easy to make your own special remote that implements import only. Using whatever ssh commands make sense for the server.

This did get implemented, git config annex.assistant.allowunlocked true and that will make it use your annex.addunlocked setting.

quick check -- according to ls - original inodes are not mapped but some are given and persist across remounts:

❯ ls -li /tmp/glances-root.log ~/.emacs ~/20250807-15forzabava.pdf
   132280 lrwxrwxrwx 1 yoh  yoh      17 Nov 11  2014 /home/yoh/.emacs -> .etc/emacs/.emacs
152278557 -rw-rw-r-- 1 yoh  yoh  207101 Aug  7 10:30 /home/yoh/20250807-15forzabava.pdf
       34 -rw-r--r-- 1 root root   1165 Oct  1 08:43 /tmp/glances-root.log

❯ sshfs localhost:/ /tmp/localhost

❯ ls -li /tmp/localhost{/tmp/glances-root.log,/home/yoh/{.emacs,20250807-15forzabava.pdf}}
 6 lrwxrwxrwx 1 yoh  yoh      17 Nov 11  2014 /tmp/localhost/home/yoh/.emacs -> .etc/emacs/.emacs
10 -rw-rw-r-- 1 yoh  yoh  207101 Aug  7 10:30 /tmp/localhost/home/yoh/20250807-15forzabava.pdf
 3 -rw-r--r-- 1 root root   1165 Oct  1 08:43 /tmp/localhost/tmp/glances-root.log

❯ fusermount -u /tmp/localhost

❯ sshfs localhost:/ /tmp/localhost

❯ ls -li /tmp/localhost{/tmp/glances-root.log,/home/yoh/{.emacs,20250807-15forzabava.pdf}}
 6 lrwxrwxrwx 1 yoh  yoh      17 Nov 11  2014 /tmp/localhost/home/yoh/.emacs -> .etc/emacs/.emacs
10 -rw-rw-r-- 1 yoh  yoh  207101 Aug  7 10:30 /tmp/localhost/home/yoh/20250807-15forzabava.pdf
 3 -rw-r--r-- 1 root root   1165 Oct  1 08:43 /tmp/localhost/tmp/glances-root.log

ok, if not sshfs and not rsync -- any other way you see? e.g. could it be easily setup for some git with ssh URL type "special" remote?

I've copied the git-annex activity idea over to Recent remote activities so it doesn't get lost.

I don't think it makes sense to make that a blocker for removing the webapp though. That would only let an advanced user build some kind of activity display, doesn't address the needs of most users of the webapp.

`git annex activity --since="2 weeks ago" --include='*.doc'

This is essentially the same as git-annex log with a path. It also supports --since and --json. The difference I guess is the idea to also include information about git commits of the files, not only git-annex location changes. That would complicate the output, and apparently git-annex log's output is too hard to parse already. So a design for a better output would be needed.

git annex activity --only-annex --in=remote2

This is the same as git-annex log --all with the output filtered to only list a given remote. (--in does not influence --all currently).

git annex activity --only-changes --largerthan=10MB

Can probably be accomplished with git log with some -S regexp.