diff --git a/doc/forum/Fill_remotes_sequentially/comment_5_de87c0fd5ddb95c5d0e7c0c9c6b89460._comment b/doc/forum/Fill_remotes_sequentially/comment_5_de87c0fd5ddb95c5d0e7c0c9c6b89460._comment
new file mode 100644
index 0000000000..037e64d4ff
--- /dev/null
+++ b/doc/forum/Fill_remotes_sequentially/comment_5_de87c0fd5ddb95c5d0e7c0c9c6b89460._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="stv0g"
+ avatar="http://cdn.libravatar.org/avatar/6faa6cc783a165b25fc1c8f3154ba449"
+ subject="comment 5"
+ date="2025-05-21T23:40:28Z"
+ content="""
+Thanks a lot @joey & @nobodyinperson for your input :)
+
+> I think this is the same system that there will be a talk about at Distribits 2025? I have been looking forward to that talk.
+
+Yes exactly :) I am still working on the code. But having a deadline is sometimes helpful :D
+
+> Relatedly, I wonder about sequential reading when a big git-annex get is run. Do you have some solution for that in mind?
+
+I am using the approach proposed by you in this post: https://git-annex.branchable.com/forum/Storing_copies_on_LTO_tapes__63__/
+As you noted, this is quite similar to how Glacier is handled.
+
+And yes, it would also allow batching together multiple `git-annex get` into a single sequential pass over the tape.
+I would like to also support batching together objects originating from multiple git-annex repos.
+
+But this would make it pretty difficult to track the available capacity per tape cartridge as multiple git-annex repos would contribute (or even other non git-annex files).
+
+LTO tapes are a bit special, as they are append-only. The available capacity will only decreases when new objects are added.
+The only option to regain capacity is by erasing the tape. If this happens, I am marking the git-annex remote as dead and initialize a new fresh remote.
+
+I now realized, that I can use this fact to detect the first EOT (end of tape) error for each tape and then update its preferred content expression..
+
+> Another approach would be to configure remote.<name>.annex-cost-command with a command that gives a low cost to the tape in the drive, and a high cost to other tapes.
+
+Oh that sounds really interesting. But how is this related to the `GETCOST` & `GETAVAILABILITY` messages of the external special remote protocol?
+
+It seems like that the remote's cost could be a way to define the order in which the remotes are filled?
+
+Its a lot to digest. I will start testing and playing around with your ideas.
+
+Thanks :)
+"""]]

diff --git a/doc/todo/remove_webapp/comment_2_2e6df80c2f58e4aa79191065d4f4dd76._comment b/doc/todo/remove_webapp/comment_2_2e6df80c2f58e4aa79191065d4f4dd76._comment
new file mode 100644
index 0000000000..a2c8f94bb3
--- /dev/null
+++ b/doc/todo/remove_webapp/comment_2_2e6df80c2f58e4aa79191065d4f4dd76._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-05-21T18:16:32Z"
+ content="""
+As part of removing the webapp, I patched Alerts out of the assistant in 
+[[!commit 33cf88c8b8962a7f5d3b3caada95890d5f4d377e]].
+
+It did occur to me that logging the text of the Alert might make the
+assistant's log more useful. That commit would be an easy starting point to
+adding such logging.
+
+I don't think it solves [[todo/Recent_remote_activities]] though because
+it would only show activity by the assistant, not by other commands, and
+not activity that happened in other clones of the repository.
+"""]]

diff --git a/doc/forum/Fill_remotes_sequentially/comment_3_74a9fa412d7eb07818c2c031019dd03a._comment b/doc/forum/Fill_remotes_sequentially/comment_3_74a9fa412d7eb07818c2c031019dd03a._comment
new file mode 100644
index 0000000000..27aca24f16
--- /dev/null
+++ b/doc/forum/Fill_remotes_sequentially/comment_3_74a9fa412d7eb07818c2c031019dd03a._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2025-05-21T17:06:51Z"
+ content="""
+As to the ordering, at first I thought it would make sense for it to
+pick the most full repository that still has space for a file.
+
+But: Suppose that the files being processed alternate between large, and
+small. The fullest tape is too full for any of the large files, but it can
+hold all the small files. The second fullest tape has plenty of room.
+In this case, it would constantly switch back and forth between the two tapes.
+
+sizebalanced picks the least full repository. That's not what we want
+either, clearly, since it alternates between repositories frequently when
+they're near the same size.
+
+The optimal solution is for git-annex to remember what repository was used
+to store the last file, and can just use that repository again. Unless it's
+full, in which case it can pick any repository that still has space. And
+then it will continue to use that new repository for subsequent files.
+
+That memory would necessarily be local to a repository in front of these
+tape remotes. (Eg, a cluster gateway). If there were multiple repositories
+that were all writing to the same tape remotes, they would each have their
+own memory, and chaos would ensue. 
+
+Needing a memory makes me a bit dubious about putting this in a preferred
+content expression. But in your specific case, I guess it would work.
+"""]]
diff --git a/doc/forum/Fill_remotes_sequentially/comment_4_c9e1698e33432ae7cb61cd13706717b3._comment b/doc/forum/Fill_remotes_sequentially/comment_4_c9e1698e33432ae7cb61cd13706717b3._comment
new file mode 100644
index 0000000000..3fdf6d9e38
--- /dev/null
+++ b/doc/forum/Fill_remotes_sequentially/comment_4_c9e1698e33432ae7cb61cd13706717b3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2025-05-21T18:05:27Z"
+ content="""
+Another approach would be to configure `remote.<name>.annex-cost-command`
+with a command that gives a low cost to the tape in the drive, and a high
+cost to other tapes.
+
+But git-annex only checks the cost once at startup. It would need to check
+it again after each file. Which could be a new configuration setting. You
+would need to make the cost command efficent enough that running it once per
+file is not too slow.
+
+With this approach, the standard archive group preferred content 
+would probably suffice.
+"""]]

diff --git a/doc/forum/Fill_remotes_sequentially/comment_2_ad18dd206fc6b8a6cc3e11cd4d13a351._comment b/doc/forum/Fill_remotes_sequentially/comment_2_ad18dd206fc6b8a6cc3e11cd4d13a351._comment
new file mode 100644
index 0000000000..2f3af14153
--- /dev/null
+++ b/doc/forum/Fill_remotes_sequentially/comment_2_ad18dd206fc6b8a6cc3e11cd4d13a351._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-05-21T16:39:53Z"
+ content="""
+I think this is the same system that there will be a talk about at
+Distribits 2025? I have been looking forward to that talk.
+
+@nobodyinperson seems on the right track with the `sequential=tape:1` idea.
+And it seems fairly easy to implement using the same building blocks as
+`sizebalanced`.
+
+Relatedly, I wonder about sequential reading when a big `git-annex get`
+is run. Do you have some solution for that in mind? I could imagine doing
+something similar to Amazon Glacier, where the first get of a file fails,
+but is queued for later retrival from tape, allowing multiple requests to
+be ordered more efficiently.
+"""]]

diff --git a/doc/forum/Fill_remotes_sequentially/comment_1_eb69c2ab5c64683ab36ef26a45dd32f5._comment b/doc/forum/Fill_remotes_sequentially/comment_1_eb69c2ab5c64683ab36ef26a45dd32f5._comment
index 8c92b6244c..86d8223368 100644
--- a/doc/forum/Fill_remotes_sequentially/comment_1_eb69c2ab5c64683ab36ef26a45dd32f5._comment
+++ b/doc/forum/Fill_remotes_sequentially/comment_1_eb69c2ab5c64683ab36ef26a45dd32f5._comment
@@ -6,5 +6,5 @@
  content="""
 It sounds like *maybe* the new `sizebalanced=tape:1` expression could help here? 🤔 But if I understand correctly, it would try to fill the tapes up equally, which is not what you want. There would need to be something like `sequential=tape:1`, which doesn't want to balance the annexes in terms of size, but just in order. But what order? 🤔 Ordered by descending filled annex size? That would be what you need I think.
 
-https://git-annex.branchable.com/git-annex-preferred-content/#:~:text=sizebalanced=groupname
+[git-annex-preferred-content](https://git-annex.branchable.com/git-annex-preferred-content/#:~:text=sizebalanced=groupname)
 """]]

diff --git a/doc/forum/Fill_remotes_sequentially/comment_1_eb69c2ab5c64683ab36ef26a45dd32f5._comment b/doc/forum/Fill_remotes_sequentially/comment_1_eb69c2ab5c64683ab36ef26a45dd32f5._comment
new file mode 100644
index 0000000000..8c92b6244c
--- /dev/null
+++ b/doc/forum/Fill_remotes_sequentially/comment_1_eb69c2ab5c64683ab36ef26a45dd32f5._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Maybe the new sizebalanced= feature?"
+ date="2025-05-21T14:04:50Z"
+ content="""
+It sounds like *maybe* the new `sizebalanced=tape:1` expression could help here? 🤔 But if I understand correctly, it would try to fill the tapes up equally, which is not what you want. There would need to be something like `sequential=tape:1`, which doesn't want to balance the annexes in terms of size, but just in order. But what order? 🤔 Ordered by descending filled annex size? That would be what you need I think.
+
+https://git-annex.branchable.com/git-annex-preferred-content/#:~:text=sizebalanced=groupname
+"""]]

diff --git a/doc/forum/Fill_remotes_sequentially.mdwn b/doc/forum/Fill_remotes_sequentially.mdwn
new file mode 100644
index 0000000000..05b7c110a1
--- /dev/null
+++ b/doc/forum/Fill_remotes_sequentially.mdwn
@@ -0,0 +1,9 @@
+I am currently working on a new special remote for storing git-annex objects on tape media.
+In my setup every tape cartridge is tracked by git-annex as a dedicated special remote.
+All these remotes are part of a new `tape` group.
+
+I would like to use a preferred content expression similar to the `archive` standard group: `(not copies=tape:1) or approxlackingcopies=1`.
+
+However, with having many tapes (remotes) which would match this expression, I would like to choose only one of the as the target (and always the same one) until it is full.
+
+This is necessary, as I need to avoid frequently swapping cartridges from the tape drive to minimize wear.

diff --git a/doc/todo/remove_webapp/comment_1_445fef0c0c9ca2c54e76bb66bafbf214._comment b/doc/todo/remove_webapp/comment_1_445fef0c0c9ca2c54e76bb66bafbf214._comment
new file mode 100644
index 0000000000..68e7fdfc6f
--- /dev/null
+++ b/doc/todo/remove_webapp/comment_1_445fef0c0c9ca2c54e76bb66bafbf214._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="Valid reasons to retire the webapp, how about "
+ date="2025-05-21T08:22:28Z"
+ content="""
+These are all valid reasons to retire the webapp. The webapp lacks many features that it would need to be really useful. Also creation of new repos or addition of existing repos into the webapp is not as straightforward as it should be to make it similar in usability like e.g. syncthing.
+
+I do still use it for shared family folders on my and their machines. It's nice to have something to tell people to click on, then something happens and they can see if syncing works or does anything. `git annex info` is not quite the same, though it shows active transfers.
+
+What I would love to see as a replacement for the webapp is a command like `git annex assistant-status` that maybe outputs as json of human-readable text what the assitant currently does (pulling, merging, pushing to which remote, downloading, uploading, etc.), all the stuff that was nicely visible in the webapp. (Does this exist already? 🤔)
+
+Furthermore, a command like `git annex activity` that goes arbitrarily far back in time and statically (non-live) lists recent activities like:
+
+- yesterday 23:32: remote1 downloaded 5 files (45MB)
+- today 10:45: you modified file `document.txt` (10MB)
+- today 10:46: you uploaded file `document.txt` (from today 10:45) to remote1, remote2 and remote3
+- today 12:35: Fred McGitFace modified file `document.txt` (12MB) and uploaded to remote2
+- ...
+
+Basically a human-readable (or as JSON), chronological log of things that happened in the repo. This is a superpower of git-annex: all this information is available as far back as one wants, we just don't have a way to access it nicely. `git log` and `git annex log` exist, but they are too specific, too broad or a bit hard to parse on their own. For example:
+
+- `git annex activity --since=\"2 weeks ago\" --include='*.doc'` would list things (who committed, which remote received it, etc.) that happened in the last two weeks to *.doc files
+- `git annex activity --only-annex --in=remote2` would list recent annex operations (in the `git-annex` branch only) of remote2
+- `git annex activity --only-changes --largerthan=10MB` would list recent file changes (additions, modifications, deletions, etc., in `git log` only)
+
+This `git annex assistant-log` and `git annex activity` would be a very nice feature to showcase git-annex's power (which other file syncing tool can to this? 🤔) and also solve [[todo/Recent_remote_activities]].
+"""]]

diff --git a/doc/todo/remove_webapp.mdwn b/doc/todo/remove_webapp.mdwn
new file mode 100644
index 0000000000..14223a1706
--- /dev/null
+++ b/doc/todo/remove_webapp.mdwn
@@ -0,0 +1,43 @@
+I am considering removing the `git-annex webapp`. Your feedback is
+appreciated if you still use it. --[[Joey]]
+
+The assistant would be retained, so existing setups that were configured
+with the webapp would keep working, although users of those would need to
+replace any use of the webapp to control them with command-line use.
+
+The webapp has been only minimally maintained for about 10 years. There
+have been no new features, and while it amazingly continues to work, it
+doesn't addess many of the changes in git-annex. For example, there's no
+way to configure exporttree special remotes in the webapp.
+
+I think the webapp is barely used by git-annex users. The point of it was
+to make git-annex easy enough to set up to reach a larger user base. That
+necessarily meant building something that aspired to be more like dropbox
+than git. That never really happened. git-annex found its own user bases
+that appreciate its actual strengths, and who have helped build it in the
+directions where more and more people find it useful.
+
+Keeping the webapp in git-annex has a price. It has a complex and
+annoying dependency chain. (See [[ditch_yesod]].)
+It uses template haskell, which makes build times slow, and makes
+building use a lot more memory.
+
+The webapp also has some security exposure that stock git-annex does not
+have. Beyond the business of connecting to the webapp securely, the adhoc
+network protocol used by the webapp's pairing interface is baked into the
+assistant even when the webapp is not being used. And is not otherwise used
+in git-annex, and has had at least one security issue in the past.
+
+The git-annex binary also ends up significantly larger due to containing
+the webapp. And removing it deletes 28 thousand lines of code from
+git-annex, including embedded code copies of bootstrap and jquery.
+
+----
+
+The `removewebapp` branch has a working patch to remove the webapp.
+
+Documentation that mentions the webapp, including doc/git-annex-webapp.mdwn
+still would need to be updated.
+
+Also annex.autoupgrade needs to be updated, one of the options was webapp
+specific. Maybe upgrades are out of scope for the assistant too?

diff --git a/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_3_21962c77c93a14a3d1eaf3658f556ee8._comment b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_3_21962c77c93a14a3d1eaf3658f556ee8._comment
new file mode 100644
index 0000000000..e80e645db9
--- /dev/null
+++ b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_3_21962c77c93a14a3d1eaf3658f556ee8._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2025-05-20T15:00:07Z"
+ content="""
+I see, in my case I have no git lock files but rather a lock file for our process:
+
+```
+reprostim@reproiner:/data/reprostim$ ls -ld .git/*.lock
+-rw-r--r-- 1 reprostim reprostim 0 May  8 13:51 .git/reprostim-videocapture.lock
+
+```
+
+which I guess `git-annex` treats as a git lock file.  Is there a way to make them two play nicely without me coming up with some alternative location which is to be ignored by git but local to this repository? May be only known to belong to `git` lock files should be considered?  Or may be me placing it under `.git/reprostim-videocapture/lock` would be satisfactory? (do not want to interrupt ATM - doing useful stuff)
+
+After all both of them \"are not git\" (in that they both also use `.git/` space for their own needs) ;-)
+
+
+"""]]

diff --git a/doc/news/version_10.20241202.mdwn b/doc/news/version_10.20241202.mdwn
deleted file mode 100644
index 0c3b2f2cfc..0000000000
--- a/doc/news/version_10.20241202.mdwn
+++ /dev/null
@@ -1,28 +0,0 @@
-git-annex 10.20241202 released with [[!toggle text="these changes"]]
-[[!toggleable text="""  * add: Consistently treat files in a dotdir as dotfiles, even
-    when ran inside that dotdir.
-  * add: When adding a dotfile as a non-large file, mention that it's a
-    dotfile.
-  * p2phttp: Added --directory option which serves multiple git-annex
-    repositories located inside a directory.
-  * When remote.name.annexUrl is an annex+http(s) url, that
-    uses the same hostname as remote.name.url, which is itself a http(s)
-    url, they are assumed to share a username and password. This avoids
-    unnecessary duplicate password prompts.
-  * git-remote-annex: Fix a reversion introduced in version 10.20241031
-    that broke cloning from a special remote.
-  * git-remote-annex: Fix cloning from a special remote on a crippled
-    filesystem.
-  * git-remote-annex: Fix buggy behavior when annex.stalldetection is
-    configured.
-  * git-remote-annex: Require git version 2.31 or newer, since old
-    ones had a buggy git bundle command.
-  * S3: Support versioning=yes with a readonly bucket.
-    (Needs aws-0.24.3)
-  * S3: Send git-annex or other configured User-Agent.
-    (Needs aws-0.24.3)
-  * S3: Fix infinite loop and memory blowup when importing from an
-    unversioned S3 bucket that is large enough to need pagination.
-  * S3: Use significantly less memory when importing from a
-    versioned S3 bucket.
-  * vpop: Only update state after successful checkout."""]]
\ No newline at end of file
diff --git a/doc/news/version_10.20250102.mdwn b/doc/news/version_10.20250102.mdwn
deleted file mode 100644
index bc80c217d8..0000000000
--- a/doc/news/version_10.20250102.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-git-annex 10.20250102 released with [[!toggle text="these changes"]]
-[[!toggleable text="""  * Added config `url.<base>.annexInsteadOf` corresponding to git's
-    `url.<base>.pushInsteadOf`, to configure the urls to use for accessing
-    the git-annex repositories on a server without needing to configure
-    remote.name.annexUrl in each repository.
-  * Work around git hash-object --stdin-paths's odd stripping of carriage
-    return from the end of the line (some windows infection), avoiding
-    crashing when the repo contains a filename ending in a carriage return.
-  * Document that settting preferred content to "" is the same as the
-    default unset behavior.
-  * sync: Avoid misleading warning about future preferred content
-    transition when preferred content is set to "".
-  * Honor annex.addunlocked configuration when importing a tree from a
-    special remote.
-  * Removed the i386ancient standalone tarball build for linux, which
-    was increasingly unable to support new git-annex features.
-  * Removed support for building with ghc older than 9.0.2,
-    and with older versions of haskell libraries than are in current Debian
-    stable.
-  * stack.yaml: Update to lts-23.2."""]]
\ No newline at end of file
diff --git a/doc/news/version_10.20250520.mdwn b/doc/news/version_10.20250520.mdwn
new file mode 100644
index 0000000000..07a4e9c893
--- /dev/null
+++ b/doc/news/version_10.20250520.mdwn
@@ -0,0 +1,12 @@
+git-annex 10.20250520 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Preferred content now supports "balanced=groupname:lackingcopies"
+    to make files be evenly balanced amoung as many repositories as are
+    needed to satisfy numcopies.
+  * map: Fix buggy handling of remotes that are bare git repositories
+    accessed via ssh.
+  * map: Avoid looping forever with mutually recursive paths between
+    repositories accessed via ssh.
+  * whereused: Fix bug that could find matches from grafts
+    in remote git-annex branches.
+  * Windows: Fix bug that can cause git status to show annexed files as
+    modified when built with OsPath."""]]
\ No newline at end of file

diff --git a/doc/todo/compute_special_remote.mdwn b/doc/todo/compute_special_remote.mdwn
index 5b9fa5bca3..6803e9b466 100644
--- a/doc/todo/compute_special_remote.mdwn
+++ b/doc/todo/compute_special_remote.mdwn
@@ -62,3 +62,6 @@ I believe that no particular handling of annex key that are declared inputs to c
 We would need a way for users to indicate that they trust a particular compute introduction or the entity that provided it. Even if git-annex does not implement tooling for that, it would be good to settle on a concept that can be interpreted/implemented by such special remotes.
 
 [[!tag projects/INM7]]
+
+> [[done]], with [[compute_special_remote_remaining_todos]] having some
+> more things that could be done to improve this. --[[Joey]]

diff --git a/doc/bugs/performance_regression__63___init_takes_times_more.mdwn b/doc/bugs/performance_regression__63___init_takes_times_more.mdwn
index 349fd48937..83a152c34f 100644
--- a/doc/bugs/performance_regression__63___init_takes_times_more.mdwn
+++ b/doc/bugs/performance_regression__63___init_takes_times_more.mdwn
@@ -55,3 +55,9 @@ Since difference is quite substantial I have decided to file this issue.
 [[!meta author=yoh]]
 [[!tag projects/dandi]]
 
+> I have decided to close this, it seems plausible that the additional
+> overhead of reconcileStaged that I was measuring is not something that
+> can be eliminated. Measurement error also is possible. Since I made
+> several optimisations and persistent-sqlite got optimised as well, and
+> since the scan was moved to not happen at init time, this should no
+> longer be a problem. [[done]] --[[Joey]]

diff --git a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__.mdwn b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__.mdwn
index af10cc024d..21aeb27a94 100644
--- a/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__.mdwn
+++ b/doc/bugs/too_aggressive_in_claiming___34__Transfer_stalled__34____63__.mdwn
@@ -71,3 +71,5 @@ first was a year old version, then tried with bleeding edge 10.20231227+git24-gd
 
 [[!meta author=yoh]]
 [[!tag projects/dandi]]
+
+> Looks like I probably addressed this, so closing. [[done]] --[[Joey]]

diff --git a/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished/comment_2_5f2183eaf48075baf3abc2d302fc828d._comment b/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished/comment_2_5f2183eaf48075baf3abc2d302fc828d._comment
new file mode 100644
index 0000000000..b9096e28f8
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished/comment_2_5f2183eaf48075baf3abc2d302fc828d._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="mak"
+ avatar="http://cdn.libravatar.org/avatar/22a5cc617809fed3c309300a28e8adc4"
+ subject="git-annex and starship"
+ date="2025-05-20T04:06:38Z"
+ content="""
+I arrived here because I was having the same issue. At least in my case, the issue seems to stem from the `git_status` module in starship. I know this is not the best solution, but I was able to stop this issue by increasing the value of `command_timeout` in my starship config. Another potential solution might be to use `gitoxide` for checking the status of the repository with starship (my assumption here is that `gitoxide` might be faster than regular git for checking the status of the repository).
+"""]]

diff --git a/doc/forum/Scalability_Issues/comment_2_76087a3733f97655a825c96a2345db36._comment b/doc/forum/Scalability_Issues/comment_2_76087a3733f97655a825c96a2345db36._comment
new file mode 100644
index 0000000000..57fb6d240a
--- /dev/null
+++ b/doc/forum/Scalability_Issues/comment_2_76087a3733f97655a825c96a2345db36._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="cznug"
+ avatar="http://cdn.libravatar.org/avatar/fc76e1657886a3bb6f2905c554d0f80c"
+ subject="comment 2"
+ date="2025-05-16T08:29:33Z"
+ content="""
+Thanks a lot **joey** for your help.
+
+I gave it another try without setting the metadata and by using v4 index.
+
+Instead of directly adding all files to the gateway repository, I distributed the files equally across the 16 nodes to make use of their resources.
+On each node I added the file portion to a git-annex repository in order to merge them later via the gateway repository.
+Adding the files on each node worked very well using the `--jobs=\"cpus\"` flag.
+
+However, once I tried to merge all 16 repos using `git-annex sync --no-content --allow-unrelated-histories --jobs=\"cpus\"` all of the nodes crashed due to out-of-memory during this step:
+
+`remote: (merging synced/git-annex bigserver/git-annex into git-annex...)`
+
+I assume that you are right and that I simply have too many files.
+
+Unfortunately, I currently cannot spend more time on investigating the issues.
+Thanks again for your help. :)
+"""]]

diff --git a/doc/bugs/Re-Adjust_Loses_Commits.mdwn b/doc/bugs/Re-Adjust_Loses_Commits.mdwn
new file mode 100644
index 0000000000..bc0f236553
--- /dev/null
+++ b/doc/bugs/Re-Adjust_Loses_Commits.mdwn
@@ -0,0 +1,80 @@
+Hey there,
+
+I have come across a condition that leads to the "loss" of commits.
+
+### Please describe the problem.
+After merging some branch into an adjusted branch, git annex can no longer sync the adjusted branch with the main branch. `git annex sync` prints `unable to propagate merge commit Ref "XXX" back to Ref "refs/heads/main"`, however the exit code does not indicate failure.
+
+Based on this statement from the adjust man page:
+> Re-running  this  command with the same options while inside the adjusted branch will update the adjusted branch as necessary (eg for --hide-missing and --unlock-present), and will also propagate commits back to the original branch.
+
+I re-adjusted the branch. However, this printed the same warning, but reset the adjusted branch back to main, leading to the loss of all commits only present in the adjusted branch.
+
+### What steps will reproduce the problem?
+The sequence of commands below reproduces the issue. Create a fresh git-annex repository and create some commit in it. Then create a new branch and adding a commit there. Switch back to the main branch, and adjust it. Merge the new branch into the adjusted branch. Create some more commits in the adjusted branch. Try to sync the adjusted branch with the main branch. `git annex sync` fails, while `git annex adjust` leads to the loss of the second and third commit.
+
+```sh
+# Setup Repo
+mkdir test && cd test
+git init
+git annex init
+
+# Add first data
+echo "Some first data" > 01
+git annex add 01
+git commit -m "Add first data"
+
+# Create adjusted branch
+git annex adjust --hide-missing --unlock
+
+# Branch of main and add data
+git switch main
+git switch -c new
+echo "Some second data" > 02
+git annex add 02
+git commit -m "Add second data"
+
+# Merge new branch into adjusted
+git switch "adjusted/main(hidemissing-unlocked)"
+git merge new --no-edit
+
+# Add more data to adjusted
+echo "Some third data" > 03
+git annex add 03
+git commit -m "Add third data"
+
+# Try to sync adjusted with main
+# This reports "unable to propagate merge commit Ref XXX back to Ref "refs/heads/main"
+git annex sync
+
+# Try to sync by re-adjusting
+# Also reports the unable to propagate, but also resets "adjusted/main(hidemissing-unlocked)" to the very first commit, loosing two subsequent two
+git annex adjust --hide-missing --unlock
+```
+
+### What version of git-annex are you using? On what operating system?
+
+Version 10.20250416-X on Linux:
+
+```sh
+ 󰛒 git annex version
+git-annex version: 10.20250416-gb22a72cd9444071e86a46cc1eb8799e7d085b49d
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.8 http-client-0.7.17 persistent-sqlite-2.13.1.0 torrent-10000.1.3 uuid-1.3.16 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL GITBUNDLE GITMANIFEST VURL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg rclone hook external compute mask
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+```
+
+But it also occurred on a macOS system, of which I do not have the version at hand.
+
+### Please provide any additional information below.
+Do you know how I can recover the lost commits?
+
+### Have you had any luck using git-annex before?
+Git-annex is such a great piece of software, thanks for creating it. I use it to manage my photography archive. I have a main branch that contains all my images and that I sync and backup across various devices. When adding new images to the archive I create a branch just containing those new images. After culling those photos, I merge it into main. Git-annex does a perfect jobs with this.
+But now I started using some SW that cannot deal with symlinks, so I use an adjusted branch of main. Merging the new import branch into the adjusted branch leads to the described issue.
+
+Many thanks and have a great day!

diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_6_90bdc29882c09a7e002c3cfd80ba8bfc._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_6_90bdc29882c09a7e002c3cfd80ba8bfc._comment
new file mode 100644
index 0000000000..d8e02d92b2
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_6_90bdc29882c09a7e002c3cfd80ba8bfc._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="liam"
+ avatar="http://cdn.libravatar.org/avatar/5cb416d010c1d3f0ca677dd7f6c822ea"
+ subject="How to mitigate not finding git-annex-shell on MacOS remote?"
+ date="2025-05-15T02:35:31Z"
+ content="""
+As a solution to my own question, for anyone who stumbles upon this with the same problem...
+You don't have to set the path on the remote machine to get this working.
+
+On the local machine, simply do: `git config remote.macbook-remote.annex-shell /usr/local/bin/git-annex-shell`
+Then do: `git annex enableremote macbook-remote`
+Finally, `git annex sync macbook-remote` to sync it with the remote one.
+
+See: [[https://git-annex.branchable.com/tips/get_git-annex-shell_into_PATH/]]
+
+I don't think this really fixed whatever weirdness is going on with the remote, but thankfully the tip works.
+"""]]

diff --git a/doc/forum/not_finding_git-annex-shell_on_remote/comment_5_9592297b8d22822997eb09a4953d8f64._comment b/doc/forum/not_finding_git-annex-shell_on_remote/comment_5_9592297b8d22822997eb09a4953d8f64._comment
new file mode 100644
index 0000000000..c116a80e89
--- /dev/null
+++ b/doc/forum/not_finding_git-annex-shell_on_remote/comment_5_9592297b8d22822997eb09a4953d8f64._comment
@@ -0,0 +1,40 @@
+[[!comment format=mdwn
+ username="liam"
+ avatar="http://cdn.libravatar.org/avatar/5cb416d010c1d3f0ca677dd7f6c822ea"
+ subject="How to mitigate not finding git-annex-shell on MacOS remote?"
+ date="2025-05-15T02:08:58Z"
+ content="""
+I have a similar issue on MacOS with git-annex installed via homebrew.
+
+I'm trying to do `git annex sync macbook-remote` which is setup as a remote pointing to `ssh://macbook-remote:/Users/me/annex`.
+
+I get the messages:
+
+```
+Unable to parse git config from macbook-remote
+Remote macbook-remote does not have git-annex installed; setting annex-ignore
+This could be a problem with the git-annex installation on the remote. Please make sure that git-annex-shell is available in PATH when you ssh into the remote.
+Once you have fixed the git-annex installation, run: git annex enableremote macbook-remote
+```
+
+I have confirmed git-annex is installed on the remote machine, and `which git-annex` and `which git-annex-shell` both show the binaries in the `/usr/local/bin/` directory.
+
+I tried to fix it by setting the path in `~/.zprofile` of the remote machine:
+`PATH=$PATH:/usr/local/bin/git-annex-shell`
+Then I ran `git annex enableremote macbook-remote` on the local machine.
+This doesn't seem to work. It gives the same error.
+I also tried changing the path in the `.zshrc` even though from my understanding I should be setting the `.zprofile` one.
+Am I doing it wrong?
+
+What confuses me is why there is a message about parsing the git config.
+The message is not clear which git config it is talking about.
+Does this mean there is an issue with the `~/.gitconfig` file?
+Maybe it is referring to the `~/annex/.git/config` file instead?
+Maybe the shell issue is not the only problem here.
+
+Toggling verbosity / debug with the `--verbose --debug` flags doesn't seem to give any extra information to identify which file it's having problems parsing.
+
+Any insight is appreciated.
+
+Thanks
+"""]]

diff --git a/doc/install/OSX/Homebrew/comment_4_b727faa6cb65a9d0b13fc901ef41881c._comment b/doc/install/OSX/Homebrew/comment_4_b727faa6cb65a9d0b13fc901ef41881c._comment
new file mode 100644
index 0000000000..7cd54feb90
--- /dev/null
+++ b/doc/install/OSX/Homebrew/comment_4_b727faa6cb65a9d0b13fc901ef41881c._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="liam"
+ avatar="http://cdn.libravatar.org/avatar/5cb416d010c1d3f0ca677dd7f6c822ea"
+ subject="How to install man pages for git-annex?"
+ date="2025-05-15T01:10:48Z"
+ content="""
+Did anyone figure out how to get man pages to show for git-annex on mac with homebrew?
+I have installed on several macs via `brew install git-annex`.
+I don't seem to have any man pages for git-annex on my system.
+
+Thanks
+"""]]

diff --git a/doc/forum/Scalability_Issues/comment_1_50d812abc8d3531aa5311e362b684575._comment b/doc/forum/Scalability_Issues/comment_1_50d812abc8d3531aa5311e362b684575._comment
new file mode 100644
index 0000000000..1113a5d5d2
--- /dev/null
+++ b/doc/forum/Scalability_Issues/comment_1_50d812abc8d3531aa5311e362b684575._comment
@@ -0,0 +1,37 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-05-14T18:05:28Z"
+ content="""
+24 million files is a lot of files for a git repository, and is past the
+threshhold where git generally slows down, in my experience.
+
+With that said, the git-annex cluster feature is fairly new, you're the
+first person I've heard from using it at scale, and if it has its own 
+scalability problems, I'd like to address that. And I generally think it's
+cool you're using a cluster for such a large repo!
+
+Have you looked at the "balanced" preferred content expression? It is
+designed for the cluster use case and picks nodes so content gets evenly
+balanced amoung them. Without needing the overhead of setting metadata.
+
+The reason your pre-commit-annex hook script is slow is that running
+`git-annex metadata` has to update the `.git/annex/index` file, which
+you'll probably find is quite a large file. And git updates index files,
+by default by rewriting the whole file. 
+
+Needing to rewrite the index file is also probably a lot of the slow
+down of "(recording state in git...)".
+
+There are ways to make git update index files more efficiently, eg
+switching to v4 index files. Enabling split index mode can also help
+in cases where the index file is being written repeatedly. Do bear
+in mind that you would want to make these changes both to `.git/index`
+and to `.git/annex/index`
+
+Your pre-commit-annex hook is running `git-annex metadata` once per file,
+so the index gets updated once per file.
+Rather than running `git-annex metadata` in a loop, that can also 
+be sped up by using `--batch` and feed in JSON, and it will only
+need to update the index once.
+"""]]

diff --git a/doc/encryption/comment_19_ab5845de89d64b46dbc01c626b4db702._comment b/doc/encryption/comment_19_ab5845de89d64b46dbc01c626b4db702._comment
new file mode 100644
index 0000000000..a1298f866d
--- /dev/null
+++ b/doc/encryption/comment_19_ab5845de89d64b46dbc01c626b4db702._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Why is the default HMACSHA1 for shared encryption?"""
+ date="2025-05-14T17:52:30Z"
+ content="""
+This is a HMACSHA1 of the git-annex key, so for a collision to be a problem
+you would need two files whose keys collide to be stored in the repository. 
+And then the result would be that retrieving one of the files from the remote
+would fail when it verifies the downloaded file matches the hash.
+Which is not worth the bother of generating the collision.
+
+The point of using HMAC here is not cryptographic collision resistance, but
+to prevent an attacker who does not have access to the git repository 
+(and so lacks access to the HMAC secret key) from making guesses about what
+files are stored in an encrypted special remote that they do have access to.
+And HMACSHA1 accomplishes that as securely as HMACSHA256, I think.
+"""]]

diff --git a/doc/forum/git_assistant_creates_random_antagonistic_commits/comment_4_f1471089baacb15090fd1ca9160a3bfe._comment b/doc/forum/git_assistant_creates_random_antagonistic_commits/comment_4_f1471089baacb15090fd1ca9160a3bfe._comment
new file mode 100644
index 0000000000..3b3cf609be
--- /dev/null
+++ b/doc/forum/git_assistant_creates_random_antagonistic_commits/comment_4_f1471089baacb15090fd1ca9160a3bfe._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2025-05-14T17:30:12Z"
+ content="""
+The assistant is seeing changes that are made in the process of populating
+an annex pointer file with the file content on get, or replacing the file
+content with the pointer file on drop.
+
+For example, Annex/Content/PointerFile.hs in populatePointerFile
+calls removeFile before replaceWorkTreeFile. I'm not sure why it needs to
+do that, but since that's non-atomic, there's a window for the assistant
+to see the file got deleted and commit the deletion, followed by committing
+that it got added back.
+
+In depopulatePointerFile, it's more clear why it does a non-atomic
+replacement, since it calls secureErase on the file.
+
+`git config annex.delayadd 1` will probably effectively avoid the problem.
+"""]]

diff --git a/doc/forum/tell_assistant_to_wait_5_mins_before_commiting__63__/comment_3_8c87d5b914f0cff193ca7743aa55531d._comment b/doc/forum/tell_assistant_to_wait_5_mins_before_commiting__63__/comment_3_8c87d5b914f0cff193ca7743aa55531d._comment
new file mode 100644
index 0000000000..57800d6dfe
--- /dev/null
+++ b/doc/forum/tell_assistant_to_wait_5_mins_before_commiting__63__/comment_3_8c87d5b914f0cff193ca7743aa55531d._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2025-05-14T17:27:40Z"
+ content="""
+Yes, the `annex.delayadd` git configuration can be used to do this.
+It is a number of seconds for the assistant to delay before adding a
+newly created file.
+"""]]

diff --git a/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_2_c3d2b08246f2c92ef3354d25990c22c3._comment b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_2_c3d2b08246f2c92ef3354d25990c22c3._comment
new file mode 100644
index 0000000000..5ddab5ce5d
--- /dev/null
+++ b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_2_c3d2b08246f2c92ef3354d25990c22c3._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-05-14T17:05:37Z"
+ content="""
+It's pretty easy to replicate this behavior:
+
+	cat > .git/index.lock
+
+And while that process is still running, start the assistant.
+
+It might be some other ".lock" file or perhaps `.git/gc.pid` that a process
+has open for write. The assistant does not want to start running with a
+stale git lock file, which is a pretty common problem given the way that
+git lock files work. So when the lock file exists, it waits for it to have
+no writers, before removing it.
+"""]]

diff --git a/doc/bugs/assistant_does_not_add_some_of_the___40__renamed__41___files/comment_2_e5bce6560803aacd0bdcfb81f6876784._comment b/doc/bugs/assistant_does_not_add_some_of_the___40__renamed__41___files/comment_2_e5bce6560803aacd0bdcfb81f6876784._comment
new file mode 100644
index 0000000000..01c67a75da
--- /dev/null
+++ b/doc/bugs/assistant_does_not_add_some_of_the___40__renamed__41___files/comment_2_e5bce6560803aacd0bdcfb81f6876784._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-05-14T16:45:48Z"
+ content="""
+The affected files are small files, is git-annex configured to add them to git
+rather than annexing them?
+
+Are you renaming large numbers of files at once? There are
+limits to how many changes inotify can report on at one time.
+
+`.git/annex/daemon.log` might have some useful information.
+"""]]

diff --git a/doc/bugs/dead_clone_easily_dead_when_not_intended_/comment_1_2b4b806920316f39c32d30c1c875928b._comment b/doc/bugs/dead_clone_easily_dead_when_not_intended_/comment_1_2b4b806920316f39c32d30c1c875928b._comment
new file mode 100644
index 0000000000..b063197405
--- /dev/null
+++ b/doc/bugs/dead_clone_easily_dead_when_not_intended_/comment_1_2b4b806920316f39c32d30c1c875928b._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-05-14T16:29:46Z"
+ content="""
+It's not repository OR key, dead can be used with multiple keys, multiple
+repositories, or a combination of keys and repositories.
+
+(The automatically generated --help does not make it clear that --key
+can be used repeatedly, but the man page does and is correct. I guess that
+optparse-applicative --help does not try to distinguish between options
+that can be repeated vs options where a later option overrides an earlier
+one.)
+"""]]
diff --git a/doc/bugs/dead_clone_easily_dead_when_not_intended_/comment_2_92b48faedff5a46489e7bc068ef692bb._comment b/doc/bugs/dead_clone_easily_dead_when_not_intended_/comment_2_92b48faedff5a46489e7bc068ef692bb._comment
new file mode 100644
index 0000000000..aa4913e30b
--- /dev/null
+++ b/doc/bugs/dead_clone_easily_dead_when_not_intended_/comment_2_92b48faedff5a46489e7bc068ef692bb._comment
@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-05-14T16:34:22Z"
+ content="""
+I think arguably dead should be able to operate on paths too. If a user has
+lost the only copy of a file, but not deleted the annex link, it would
+be easier to use the path than looking up the key.
+
+Since dead refuses to do anything when there's still a recorded location for
+a key, there would not be any risk of operating on files whose data has not
+been lost.
+
+(There would be some ambiguity, eg "." can refer to both the "here"
+repository, or all files in the current directory. For that matter,
+the name of a repository could also be ambiguous with a filename.)
+
+Making it reject "here" when provided with additional parameters that are
+not repositories would conflict with such a change. 
+
+I realize that it's annoying to make a mistake like you made, but it's also
+not hard to undo it once you realize that you've made "here" dead.
+
+A better guard against that mistake might be for it to refuse to mark the
+current repository as dead, since it still exists. But there are probably
+workflows where a repository gets marked as dead just before `rm -rf` of it,
+which that would break.
+"""]]

diff --git a/doc/encryption/comment_18_7aa7dfcf927ca26cc51d0c2148674e53._comment b/doc/encryption/comment_18_7aa7dfcf927ca26cc51d0c2148674e53._comment
new file mode 100644
index 0000000000..7e7c8f96e4
--- /dev/null
+++ b/doc/encryption/comment_18_7aa7dfcf927ca26cc51d0c2148674e53._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="liam"
+ avatar="http://cdn.libravatar.org/avatar/5cb416d010c1d3f0ca677dd7f6c822ea"
+ subject="Why is the default HMACSHA1 for shared encryption?"
+ date="2025-05-14T16:04:11Z"
+ content="""
+I see that the shared encryption seems to use HMACSHA1 as the default.
+The https://git-annex.branchable.com/backends/ page indicates that SHA256E is the default backend used for the unencrypted key value store.
+
+Is there a reason why the default for shared encryption is not HMACSHA256 to match the default used by unencrypted repos?
+
+Does using HMACSHA1 present any caveats?
+I imagine something like collisions more likely with the older hashing algorithm.
+However, I don't know enough about how it works to make a good judgement on that.
+
+Any insight is appreciated.
+
+Thanks
+"""]]

diff --git a/doc/forum/Standalone_builds_in_nix/comment_2_0fcf50b9b66ed93893b4ea974635f180._comment b/doc/forum/Standalone_builds_in_nix/comment_2_0fcf50b9b66ed93893b4ea974635f180._comment
new file mode 100644
index 0000000000..a15ccec741
--- /dev/null
+++ b/doc/forum/Standalone_builds_in_nix/comment_2_0fcf50b9b66ed93893b4ea974635f180._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2025-05-13T16:04:52Z"
+ content="""
+Alright, thanks for the archive.org hint, noted! Indeed, going back in the repo history, at some point in September/October 2024 builds start to appear in the web remote on archive.org. 👍
+
+For the record, related thread: [[forum/standalone_tarballs_for_specific_versions]]
+"""]]

diff --git a/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished/comment_1_f4e0b61203f2f90be5f53003a6b08b52._comment b/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished/comment_1_f4e0b61203f2f90be5f53003a6b08b52._comment
new file mode 100644
index 0000000000..e335e1bda2
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished/comment_1_f4e0b61203f2f90be5f53003a6b08b52._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-05-13T15:06:43Z"
+ content="""
+I've seen this message before with `git-annex version | head -n 1`
+
+That particular one was made to ignore the error to write to stdout after
+it was closed, but any other write to stdout might fail similarly when
+going to a pipe that got closed.
+
+So can you please track down what git-annex command is being run? My
+suggestion is to use `strace -f`
+"""]]

diff --git a/doc/forum/Does___96__fsck_--more__96___imply___96__--incremental__96____63__/comment_3_275e3fb3641f74c0cff26ce3c644a8f2._comment b/doc/forum/Does___96__fsck_--more__96___imply___96__--incremental__96____63__/comment_3_275e3fb3641f74c0cff26ce3c644a8f2._comment
new file mode 100644
index 0000000000..87b9d6cd64
--- /dev/null
+++ b/doc/forum/Does___96__fsck_--more__96___imply___96__--incremental__96____63__/comment_3_275e3fb3641f74c0cff26ce3c644a8f2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2025-05-13T15:05:43Z"
+ content="""
+Yes, and I think the current docs on the man page make that clear.
+"""]]

diff --git a/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_.mdwn b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_.mdwn
index 6516f0a9ec..c917398f38 100644
--- a/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_.mdwn
+++ b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_.mdwn
@@ -63,3 +63,5 @@ run `git annex map` in my situation
 
 [[!meta author=yoh]]
 [[!tag projects/openneuro]]
+
+> [[done]] I think --[[Joey]]

diff --git a/doc/news/version_10.20250416/comment_4_b6ac0341afd1c15eed0af4161db9c021._comment b/doc/news/version_10.20250416/comment_4_b6ac0341afd1c15eed0af4161db9c021._comment
new file mode 100644
index 0000000000..83d87f4084
--- /dev/null
+++ b/doc/news/version_10.20250416/comment_4_b6ac0341afd1c15eed0af4161db9c021._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2025-05-13T14:55:52Z"
+ content="""
+First of all, a news item for a release is not the appropriate place to
+discuss something like this. Use the [[forum]] in the furture.
+
+This looks like a `.git/annex/index` that references a git object that for
+some reason didn't get written to disk. A common way this can happen is a
+disk getting unmounted or system shutdown at a point in time that causes a
+recently written git object to get lost. Deleting `.git/annex/index` will
+solve this problem.
+"""]]

diff --git a/doc/special_remotes/httpalso/comment_10_1f85bfe8cff934aa4455f2f7b9c848b6._comment b/doc/special_remotes/httpalso/comment_10_1f85bfe8cff934aa4455f2f7b9c848b6._comment
new file mode 100644
index 0000000000..0462548450
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_10_1f85bfe8cff934aa4455f2f7b9c848b6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: Setup dirhash parameter for httpalso to avoid hammering server"""
+ date="2025-05-13T14:52:34Z"
+ content="""
+httpalso learns the layout of the remote, so one a process has found one
+file it will use that same layout going forward. So you should see only a
+few 404's per process.
+
+Please open a [[todo]] with details about the problem if that's not the
+case, or if that's somehow insufficient.
+"""]]

diff --git a/doc/forum/Standalone_builds_in_nix/comment_1_d2d27d2f84399d2197abbe8c1786c8f1._comment b/doc/forum/Standalone_builds_in_nix/comment_1_d2d27d2f84399d2197abbe8c1786c8f1._comment
new file mode 100644
index 0000000000..b0f98d0594
--- /dev/null
+++ b/doc/forum/Standalone_builds_in_nix/comment_1_d2d27d2f84399d2197abbe8c1786c8f1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-05-13T14:24:42Z"
+ content="""
+My downloads.kitenet.net repository has limited size and only retains old
+builds for a certain amount of time. (There are 200+ gb of old builds at
+this point.) So I would recommend making your own
+copy of the file, or using the archive.org url which you can find with
+git-annex.
+
+(I've only recently gotten uploading to archive.org working again.)
+"""]]

diff --git a/doc/tips/Internet_Archive_via_S3.mdwn b/doc/tips/Internet_Archive_via_S3.mdwn
index 9bceeb3482..b982588e4c 100644
--- a/doc/tips/Internet_Archive_via_S3.mdwn
+++ b/doc/tips/Internet_Archive_via_S3.mdwn
@@ -36,7 +36,7 @@ rather than having git-annex pick a random one; and you can optionally
 specify `x-archive-meta*` headers to add metadata as explained in their
 [documentation](http://www.archive.org/help/abouts3.txt).
 
-	# git annex initremote archive-panama type=S3 \
+	# git annex initremote archive-panama type=S3 protocol=https \
 		host=s3.us.archive.org bucket=panama-canal-lock-blueprints \
 		x-archive-meta-mediatype=texts x-archive-meta-language=eng \
                 x-archive-meta-collection=test_collection \
diff --git a/doc/tips/Internet_Archive_via_S3/comment_4_2a2ccdfe41bc56c82eaea38fcffd1123._comment b/doc/tips/Internet_Archive_via_S3/comment_4_2a2ccdfe41bc56c82eaea38fcffd1123._comment
new file mode 100644
index 0000000000..6870bdfb40
--- /dev/null
+++ b/doc/tips/Internet_Archive_via_S3/comment_4_2a2ccdfe41bc56c82eaea38fcffd1123._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2025-05-13T14:22:17Z"
+ content="""
+After the 2025 compromise of archive.org and its subsequent rebuild, it
+seems they have changed to require http be used with their S3 API. I was
+getting error 404 when using my internet archive special remote because of
+that. I fixed it by running:
+
+	git annex enableremote archive.org protocol=https
+"""]]

diff --git a/doc/install/Linux_standalone/comment_8_8a6f41d16fba1afb16cb13e438ce97d6._comment b/doc/install/Linux_standalone/comment_8_8a6f41d16fba1afb16cb13e438ce97d6._comment
new file mode 100644
index 0000000000..07a625a77d
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_8_8a6f41d16fba1afb16cb13e438ce97d6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2025-05-13T14:12:22Z"
+ content="""
+Unfortunately I was on vacation when that breakage happened, so I don't
+remember the details, but it does seem to have been fixed.
+"""]]

diff --git a/doc/bugs/SQLite3_database_disk_image_malformed/comment_2_a4673ac5f078bcc45cec192a6184d8d8._comment b/doc/bugs/SQLite3_database_disk_image_malformed/comment_2_a4673ac5f078bcc45cec192a6184d8d8._comment
new file mode 100644
index 0000000000..6373037e20
--- /dev/null
+++ b/doc/bugs/SQLite3_database_disk_image_malformed/comment_2_a4673ac5f078bcc45cec192a6184d8d8._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-05-13T14:07:17Z"
+ content="""
+You can delete the sqlite database affected by the problem and git-annex
+will recreate it as needed.
+
+Given the improved error message shows what the problem is now,
+I don't know what more can be done about this really.
+"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_7_3a0544e290a71cf5d5666e4f83c8663d._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_7_3a0544e290a71cf5d5666e4f83c8663d._comment
new file mode 100644
index 0000000000..0db67d04c1
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_7_3a0544e290a71cf5d5666e4f83c8663d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/595babb94a7609cb73c284d81467837f"
+ subject="comment 7"
+ date="2025-05-12T20:02:48Z"
+ content="""
+I had an inkling that this could involve encoding issues / non-ascii characters but I
+didn't end up approaching my tests with that particular thing in focus. Anyway, many
+thanks for fixing something that certainly had at the very least usability implications
+for us international users of git-annex (well, on Windows at least).
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index ef7fa0cf77..27cd108252 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,5 +1,8 @@
 git-annex (10.20250417) UNRELEASED; urgency=medium
 
+  * Preferred content now supports "balanced=groupname:lackingcopies"
+    to make files be evenly balanced amoung as many repositories as are
+    needed to satisfy numcopies.
   * map: Fix buggy handling of remotes that are bare git repositories
     accessed via ssh.
   * map: Avoid looping forever with mutually recursive paths between
diff --git a/Limit.hs b/Limit.hs
index 4bdd7f6e1b..d090e09d88 100644
--- a/Limit.hs
+++ b/Limit.hs
@@ -1,6 +1,6 @@
 {- user-specified limits on files to act on
  -
- - Copyright 2011-2024 Joey Hess <id@joeyh.name>
+ - Copyright 2011-2025 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -459,19 +459,26 @@ limitLackingCopies desc approx want = case readish want of
 		}
 	Nothing -> Left "bad value for number of lacking copies"
   where
-	go mi needed notpresent key = do
-		numcopies <- if approx
-			then approxNumCopies
-			else case mi of
-				MatchingFile fi -> getGlobalFileNumCopies $
-					matchFile fi
-				MatchingInfo {} -> approxNumCopies
-				MatchingUserInfo {} -> approxNumCopies
-		us <- filter (`S.notMember` notpresent)
-			<$> (trustExclude UnTrusted =<< Remote.keyLocations key)
-		let vs nhave numcopies' = numcopies' - nhave >= needed
-		return $ numCopiesCheck'' us vs numcopies
+	go mi needed notpresent key =
+		limitCheckNumCopies approx mi notpresent key vs
+	  where
+		vs nhave numcopies' = numcopies' - nhave >= needed
+
+limitCheckNumCopies :: Bool -> MatchInfo -> AssumeNotPresent -> Key -> (Int -> Int -> v) -> Annex v
+limitCheckNumCopies approx mi notpresent key vs = do
+	numcopies <- if approx
+		then approxNumCopies
+		else case mi of
+			MatchingFile fi -> getGlobalFileNumCopies $
+				matchFile fi
+			MatchingInfo {} -> approxNumCopies
+			MatchingUserInfo {} -> approxNumCopies
+	us <- filter (`S.notMember` notpresent)
+		<$> (trustExclude UnTrusted =<< Remote.keyLocations key)
+	return $ numCopiesCheck'' us vs numcopies
+  where
 	approxNumCopies = fromMaybe defaultNumCopies <$> getGlobalNumCopies
+	
 
 {- Match keys that are unused.
  - 
@@ -597,17 +604,21 @@ limitBalanced mu getgroupmap groupname = do
 
 limitBalanced' :: String -> MatchFiles Annex -> Maybe UUID -> MkLimit Annex
 limitBalanced' termname fullybalanced mu groupname = do
-	copies <- limitCopies $ if ':' `elem` groupname
-		then groupname
-		else groupname ++ ":1"
+	let checknumcopies = ":lackingcopies" `isSuffixOf` groupname
+	enoughcopies <- if checknumcopies
+		then limitLackingCopies termname False "1"
+		else limitCopies $ if ':' `elem` groupname
+			then groupname
+			else groupname ++ ":1"
+	let checkenoughcopies = if checknumcopies then id else not
 	let present = limitPresent mu
-	let combo f = f present || f fullybalanced || f copies
+	let combo f = f present || f fullybalanced || f enoughcopies
 	Right $ MatchFiles
 		{ matchAction = \lu a i ->
 			ifM (Annex.getRead Annex.rebalance)
 				( matchAction fullybalanced lu a i
 				, matchAction present lu a i <||>
-					((not <$> matchAction copies lu a i)
+					((checkenoughcopies <$> matchAction enoughcopies lu a i)
 						<&&> matchAction fullybalanced lu a i
 					)
 				)
@@ -667,11 +678,16 @@ limitFullyBalanced''
 	-> MkLimit Annex
 limitFullyBalanced'' filtercandidates termname mu getgroupmap want =
 	case splitc ':' want of
-		[g] -> go g 1
-		[g, n] -> maybe
-			(Left $ "bad number for " ++ termname)
-			(go g)
-			(readish n)
+		[g] -> go g (Right 1)
+		[g, n]
+			| n == "lackingcopies" -> go g $ 
+				Left $ \mi notpresent key -> 
+					let vs nhave numcopies = numcopies - nhave
+					in limitCheckNumCopies False mi notpresent key vs
+			| otherwise -> maybe
+				(Left $ "bad number for " ++ termname)
+				(go g . Right)
+				(readish n)
 		_ -> Left $ "bad value for " ++ termname
   where
 	go s n = limitFullyBalanced''' filtercandidates termname mu
@@ -683,13 +699,16 @@ limitFullyBalanced'''
 	-> Maybe UUID
 	-> Annex GroupMap
 	-> Group
-	-> Int
+	-> Either (MatchInfo -> AssumeNotPresent -> Key -> Annex Int) Int
 	-> MkLimit Annex
-limitFullyBalanced''' filtercandidates termname mu getgroupmap g n want = Right $ MatchFiles
-	{ matchAction = \lu -> const $ checkKey $ \key -> do
+limitFullyBalanced''' filtercandidates termname mu getgroupmap g getn want = Right $ MatchFiles
+	{ matchAction = \lu notpresent mi -> flip checkKey mi $ \key -> do
 		gm <- getgroupmap
 		let groupmembers = fromMaybe S.empty $
 			M.lookup g (uuidsByGroup gm)
+		n <- case getn of
+			Right n -> pure n
+			Left a -> a mi notpresent key
 		candidates <- filtercandidates n key groupmembers
 		let wanted = if S.null candidates
 			then False
diff --git a/doc/git-annex-preferred-content.mdwn b/doc/git-annex-preferred-content.mdwn
index 68769484dc..52c6ff225e 100644
--- a/doc/git-annex-preferred-content.mdwn
+++ b/doc/git-annex-preferred-content.mdwn
@@ -267,7 +267,7 @@ content not being configured.
   says it wants them. (Or, if annex.expireunused is set, it may just delete
   them.)
 
-* `balanced=groupname[:number]`
+* `balanced=groupname[:number|:lackingcopies]`
 
   Makes content be evenly balanced amoung repositories in the group.
   
@@ -277,9 +277,15 @@ content not being configured.
   For example, "balanced=backup:2", when there are 3 members of the backup
   group, will make each backup repository want 2/3rds of the files.
 
-  For this to work, each repository in the group should have its preferred
-  content set to the same expression. Using `groupwanted` is a good
-  way to do that.
+  Using "lackingcopies" rather than a number makes each file be balanced
+  amoung as many repositories in the group as are needed to satisfy
+  its numcopies configuration. Eg, "balanced=backup:lackingcopies", when
+  numcopies is 3 and there is 1 other copy will behave the same as
+  "balanced=backup:2".
+
+  For balancing to work, each repository in the group should have its
+  preferred content set to the same expression. Using `groupwanted` is a
+  good way to do that.
 
   The sizes of files are not taken into account, so it's possible for
   one repository to get larger than usual files and so fill up before
@@ -312,7 +318,7 @@ content not being configured.
   Note that `not balanced` not a reasonable thing to use in a preferred
   content expression for the same reasons as `not present`.
 
-* `fullybalanced=groupname[:number]`
+* `fullybalanced=groupname[:number|:lackingcopies]`
 
   This is like `balanced`, but allows moving content between repositories
   in the group at any time to keep it fully balanced.
@@ -333,7 +339,7 @@ content not being configured.
   but it allows new files to continue to be stored on the specified number
   of repositories.
 
-* `sizebalanced=groupname:number`
+* `sizebalanced=groupname[:number|:lackingcopies]`
 
   Distributes content amoung repositories in the group, keeping
   repositories proportionally full. 
@@ -373,7 +379,7 @@ content not being configured.
   Note that `not sizebalanced` not a reasonable thing to use in a preferred
   content expression for the same reasons as `not present`.
 
-* `fullysizebalanced=groupname:number`
+* `fullysizebalanced=groupname[:number|:lackingcopies]`
 
   This is like `sizebalanced`, but allows moving content between repositories
   in the group at any time to keep it fully balanced.
diff --git a/doc/todo/balanced_preferred_content_taking_numcopies_into_account.mdwn b/doc/todo/balanced_preferred_content_taking_numcopies_into_account.mdwn
new file mode 100644
index 0000000000..b98a2d0e39
--- /dev/null
+++ b/doc/todo/balanced_preferred_content_taking_numcopies_into_account.mdwn
@@ -0,0 +1,21 @@
+Using `balanced` or similar preferred content expressions makes files be
+spread amoung repositories in a group, but does not take numcopies into

(Diff truncated)

diff --git a/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group.mdwn b/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group.mdwn
index 4d29f2e5ba..2a37c19cd7 100644
--- a/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group.mdwn
+++ b/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group.mdwn
@@ -22,3 +22,5 @@ Still it would be good to support this, especially for when existing
 archive repositories get put in a cluster.)
 
 --[[Joey]] 
+
+> [[wontfix|done]]
diff --git a/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group/comment_1_74361be79de885bc35cd800a2aad4be0._comment b/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group/comment_1_74361be79de885bc35cd800a2aad4be0._comment
new file mode 100644
index 0000000000..b2bde33c2f
--- /dev/null
+++ b/doc/todo/cluster_preferred_content_parallel_evaluation_issue_with_archive_group/comment_1_74361be79de885bc35cd800a2aad4be0._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-05-12T16:03:36Z"
+ content="""
+If this were implemented, and one of the nodes was full, and that happened
+to be the node whose preferred content expression were evaluated first, it
+would try to store there and fail, and the content would not be stored in
+any of the other nodes. Which seems potentially worse than the file being
+stored on multiple nodes currently.
+
+Of course, this is the problem that `sizebalanced` preferred content
+solves. Since sizebalanced is otherwise much like the archive group,
+it would make sense to just switch the cluster nodes to use it.
+
+As for other preferred content expressions, unless they use
+`copies=groupname:number` or `lackingcopies`, whether one node wants
+content won't be influenced by what other nodes have it. So evaluating
+in preferred content in parallel is ok for those.
+
+I think I've talked myself out of making a change!
+"""]]

diff --git a/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished.mdwn b/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished.mdwn
new file mode 100644
index 0000000000..1600d0ed3e
--- /dev/null
+++ b/doc/bugs/git-annex__58_____60__stdout__62____58___hPutBuf__58___resource_vanished.mdwn
@@ -0,0 +1,47 @@
+### Please describe the problem.
+
+Randomly, in my terminal under a git-annex repository, I get the following message:
+
+```
+git-annex: <stdout>: hPutBuf: resource vanished (Broken pipe)
+```
+
+Note that despite this bug happens in background when I'm under a git-annex repository, I can still use explicit git-annex commands that are working well and do not crash.
+
+### What steps will reproduce the problem?
+
+Simply by `cd` inside one of my git-annex repositories. I think the bug is when my prompt generator (`starship`) is trying to fetch the status of the git repository under the hood.
+Moreover, this bug appeared randomly without any obvious reason, possibly under all of my repositories (not a specific one).
+
+Finally, I noticed that this bug started more or less at the same time that I did one operation:
+
+1. Copy my git-annex repositories from one external storage A to another external storage B
+
+2. Encrypt my external storage A
+
+3. Copy back from external storage B to A
+
+(But I really do not know if this is related, note that the bug is happening wherever I am on those external storage devices or on one of my local filesystems)
+
+### What version of git-annex are you using? On what operating system?
+
+- System: Arch Linux
+- Kernel: 6.14.4-arch1-2
+- Arch: amd64
+- git-annex:
+
+[[!format sh """
+git-annex version: 10.20250416-gb22a72cd9444071e86a46cc1eb8799e7d085b49d
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24 bloomfilter-2.0.1.2 crypton-0.34 DAV-1.3.4 feed-1.3.2.1 ghc-9.4.8 http-client-0.7.17 persistent-sqlite-2.13.1.0 torrent-10000.1.3 uuid-1.3.16 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL GITBUNDLE GITMANIFEST VURL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg rclone hook external compute mask
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+
+"""]]
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+This is my first post here. First, I use git-annex for both my personal files and professional datasets since around 5 years. So I have to say this wonderful piece of software helped me a lot, therefore a big thank you Joey and other contributors. ;) Second, as a reminder to myself, I really should consider to add tips to the website, since I accumulated a lot of self-wrote documentation in my notes!

diff --git a/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_1_ed38ee6263adea878d351ceb2f9da879._comment b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_1_ed38ee6263adea878d351ceb2f9da879._comment
new file mode 100644
index 0000000000..c2a7d79779
--- /dev/null
+++ b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__/comment_1_ed38ee6263adea878d351ceb2f9da879._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="also noticed some assistant weirdness"
+ date="2025-05-09T07:45:02Z"
+ content="""
+Don't know if related, but I also noticed some weirdness with the assistant lately (last 2 versions or so), where it just wouldn't push and sometimes also not commit without any apparent reason or error messages. But also `git annex assist` wouldn't do those things. It was erratic and a re-clone appeared to fix it. It feels like a repo-size thing - the problematic one is a big repo with a lot of unlocked files and I feel like those are troublemakers, often needlessly appearing as changed in `git diff`. Smaller repos no problemo. Just my doubtly helpful anecdotal evidence.
+"""]]

diff --git a/doc/forum/Standalone_builds_in_nix.mdwn b/doc/forum/Standalone_builds_in_nix.mdwn
new file mode 100644
index 0000000000..574ee5f74c
--- /dev/null
+++ b/doc/forum/Standalone_builds_in_nix.mdwn
@@ -0,0 +1,3 @@
+Nix/NixOS/nixpkgs tends to hang behind git-annex packaging, which is annoying. The standalone builds of git annex work fine when downloaded manually, but that's not the nix way ;-) Here is a derivation for the standalone builds: [git-annex-standalone.nix](https://gitlab.com/nobodyinperson/nixconfig/-/blob/c74523beb6eacf31d95d5f1a79d1558563fc82fc/pkgs/git-annex-standalone.nix). Also [this discussion](https://discourse.nixos.org/t/packaging-prebuilt-haskell-binaries/64031/1).
+
+One thing that's quite inelegant here is the lack of predictable urls for specific versions of the standalone builds. One has to grab them from the annexed content and build a sus looking download link. This also presents a bootstrapping problem as one would need git annex to do that.

diff --git a/CHANGELOG b/CHANGELOG
index f96e750319..ef7fa0cf77 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -6,6 +6,8 @@ git-annex (10.20250417) UNRELEASED; urgency=medium
     repositories accessed via ssh.
   * whereused: Fix bug that could find matches from grafts 
     in remote git-annex branches.
+  * Windows: Fix bug that can cause git status to show annexed files as
+    modified when built with OsPath.
 
  -- Joey Hess <id@joeyh.name>  Tue, 22 Apr 2025 14:33:26 -0400
 
diff --git a/Logs/File.hs b/Logs/File.hs
index ed95627883..882dc25369 100644
--- a/Logs/File.hs
+++ b/Logs/File.hs
@@ -145,6 +145,7 @@ streamLogFileUnsafe f finalizer processor = bracketOnError setup cleanup go
 	cleanup (Just h) = liftIO $ hClose h
 	go Nothing = finalizer
 	go (Just h) = do
+		liftIO $ fileEncoding h
 		mapM_ processor =<< liftIO (lines <$> hGetContents h)
 		liftIO $ hClose h
 		finalizer
diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified.mdwn b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified.mdwn
index 3a86583375..424553075c 100644
--- a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified.mdwn
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified.mdwn
@@ -524,3 +524,5 @@ say I'm a believer. :)
 
 [[!meta author=jkniiv]]
 [[!meta title="(Windows) OsPath build of git-annex shows files needlessly modified in git status"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_5_be63c011f1a7e327ce3c79125105644d._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_5_be63c011f1a7e327ce3c79125105644d._comment
new file mode 100644
index 0000000000..1461bfb3d5
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_5_be63c011f1a7e327ce3c79125105644d._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2025-05-08T18:03:11Z"
+ content="""
+In restagePointerFiles, isunmodified's call to genInodeCache is returning
+Nothing, and so it does not try to restage the file.
+
+The path to the annexed file includes "läp", and that non-ascii
+character is causing the problem. If I rename that to "lap", the problem
+goes away.
+
+Printing out the OsPath, I see `"l\195\164p"`. That seems wrong for
+Windows, where it should be using UTF-16. Calling `fromOsPath` on it to
+make a RawFilePath yields `"l\195\131\194\164p"` which is certainly wrong,
+and explains why genInodeCache, which does that conversion, is failing.
+
+So the question is how the OsPath is being constructed with the wrong
+encoding. In this case, it's coming from streamRestageLog.
+Which uses streamLogFileUnsafe. Which does not set the filesystem encoding
+when reading the log file. So that's the bug. I'm not sure if this bug is
+actually Windows specific, although the use of UTF16 on windows may be
+helping trigger a problem with it.
+
+Anyway, fixed it!
+"""]]

diff --git a/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__.mdwn b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__.mdwn
new file mode 100644
index 0000000000..dbf3f81227
--- /dev/null
+++ b/doc/bugs/assistant_does_not_commit_anything__44___waiting__63__.mdwn
@@ -0,0 +1,89 @@
+### Please describe the problem.
+
+I have used assistant on that box but forgot how I start it etc... so finally came up with a systemd recipe which seems to start it
+
+```
+reprostim@reproiner:/data/reprostim$ cat ~/.config/systemd/user/git-annex-assistant.service
+[Unit]
+Description=Git Annex Assistant Service
+After=network.target
+
+[Service]
+WorkingDirectory=/data/reprostim
+ExecStart=/usr/bin/git annex assistant --foreground
+Restart=on-failure
+RestartSec=10
+
+[Install]
+WantedBy=default.target
+```
+
+which seemed to start it nicely on booth, but I did not see anything committed/transferred. Even if I stop the systemd service, and start from terminal (remote via ssh), we see
+
+```
+reprostim@reproiner:/data/reprostim$ git annex --debug assistant --foreground
+[2025-05-08 14:08:32.609958543] (Utility.Process) process [5887] read: uname ["-o"]
+[2025-05-08 14:08:32.611617504] (Utility.Process) process [5887] done ExitSuccess
+[2025-05-08 14:08:32.614088771] (Utility.Process) process [5888] read: uname ["-o"]
+[2025-05-08 14:08:32.615900478] (Utility.Process) process [5888] done ExitSuccess
+[2025-05-08 14:08:32.617482785] (Assistant) logging to .git/annex/daemon.log
+[2025-05-08 14:08:32.618258041] (Annex.Branch) read remote.log
+[2025-05-08 14:08:32.632058148] (Utility.Process) process [5889] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2025-05-08 14:08:32.635478016] (Annex.Branch) read proxy.log
+[2025-05-08 14:08:32.636566897] (Annex.Branch) read trust.log
+[2025-05-08 14:08:32.63751056] (Assistant) logging to .git/annex/daemon.log
+```
+
+and in that daemon.log:
+
+```
+reprostim@reproiner:/data/reprostim$ cat .git/annex/daemon.log
+[2025-05-08 14:08:32.640121818] (Annex.Branch) read schedule.log
+[2025-05-08 14:08:32.64120032] (Utility.Process) process [5892] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","-c","annex.debug=true","cat-file","--batch"]
+[2025-05-08 14:08:32.655526372] (Annex.Branch) read schedule.log
+[2025-05-08 14:08:32.662389467] (Utility.Process) process [5895] read: lsof ["-F0can","--",".git/reprostim-videocapture.lock"]
+lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/113/gvfs
+      Output information may be incomplete.
+[2025-05-08 14:08:32.707976737] (Utility.Process) process [5895] done ExitSuccess
+[2025-05-08 14:08:32.708169976] (SanityCheckerStartup) Waiting for 60 seconds for git lock file writer
+[2025-05-08 14:09:32.769444892] (Utility.Process) process [6090] read: lsof ["-F0can","--",".git/reprostim-videocapture.lock"]
+lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/113/gvfs
+      Output information may be incomplete.
+[2025-05-08 14:09:32.824400459] (Utility.Process) process [6090] done ExitSuccess
+[2025-05-08 14:09:32.82450385] (SanityCheckerStartup) Waiting for 60 seconds for git lock file writer
+[2025-05-08 14:10:32.873375671] (Utility.Process) process [6281] read: lsof ["-F0can","--",".git/reprostim-videocapture.lock"]
+lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/113/gvfs
+      Output information may be incomplete.
+[2025-05-08 14:10:32.930940073] (Utility.Process) process [6281] done ExitSuccess
+[2025-05-08 14:10:32.931056974] (SanityCheckerStartup) Waiting for 60 seconds for git lock file writer
+[2025-05-08 14:11:32.992138737] (Utility.Process) process [6464] read: lsof ["-F0can","--",".git/reprostim-videocapture.lock"]
+lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/113/gvfs
+      Output information may be incomplete.
+[2025-05-08 14:11:33.063544538] (Utility.Process) process [6464] done ExitSuccess
+[2025-05-08 14:11:33.063652636] (SanityCheckerStartup) Waiting for 60 seconds for git lock file writer
+```
+
+and no new files are added/committed etc.
+
+May be I am invoking assistant incorrectly? (FWIW when I echoed that path into /home/reprostim/.config/git-annex/autostart, and start with --autostart option, then it seems to start two of the processes and still to not commit anything)
+
+
+### What version of git-annex are you using? On what operating system?
+
+```
+reprostim@reproiner:/data/reprostim$ git annex version
+git-annex version: 10.20250115-1~ndall+1
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Servant Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22.1 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.13.1 persistent-sqlite-2.13.1.0 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2.1
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL GITBUNDLE GITMANIFEST VURL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg rclone hook external
+operating system: linux x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+Please advise
+
+[[!meta author=yoh]]
+[[!tag projects/repronim]]

diff --git a/doc/bugs/assistant_does_not_add_some_of_the___40__renamed__41___files/comment_1_111477a445f75213c1ba0d47b76dbad6._comment b/doc/bugs/assistant_does_not_add_some_of_the___40__renamed__41___files/comment_1_111477a445f75213c1ba0d47b76dbad6._comment
new file mode 100644
index 0000000000..cbd966c71c
--- /dev/null
+++ b/doc/bugs/assistant_does_not_add_some_of_the___40__renamed__41___files/comment_1_111477a445f75213c1ba0d47b76dbad6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 1"
+ date="2025-05-08T17:49:56Z"
+ content="""
+issue persists, ATM using 10.20250115-1~ndall+1 . Joey please advise.
+"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_8ceac199ea2b48ef530b0488f1a15ff1._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_8ceac199ea2b48ef530b0488f1a15ff1._comment
new file mode 100644
index 0000000000..604f68a163
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_8ceac199ea2b48ef530b0488f1a15ff1._comment
@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2025-05-08T16:33:54Z"
+ content="""
+I've reproduced this.
+
+Note that running `git-annex add` on the affected files will clear up the
+problem. It manages to restage the file, and as there is no modification,
+is otherwise a no-op.
+
+As a first analysis, I looked as annex.debug output between the two
+versions of git-annex. There were no differences other than pid numbers and
+git-annex branch shas.
+
+Also, after running `git-annex get` with the bad git-annex, running `git
+status` with the good git-annex in path did not correct the problem.
+
+My current guess is that restagePointerFiles has changed its behavior in
+the filenames it sends to git update-index. In particular the comment about
+"update-index is documented as picky" about filepaths suggests a small and
+otherwise ok change to a file path could cause this breakage.
+"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_cae089a258e0fbf6cd7c52b21ee9a159._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_cae089a258e0fbf6cd7c52b21ee9a159._comment
new file mode 100644
index 0000000000..1ee8cabab0
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_cae089a258e0fbf6cd7c52b21ee9a159._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/595babb94a7609cb73c284d81467837f"
+ subject="comment 4"
+ date="2025-05-06T22:14:48Z"
+ content="""
+@Joey: you've got email. Thanks in advance for taking a look at my problem. I forgot
+to mention in the email that you really need to comment or remove the line with
+`git config core.autocrlf false` from my init script (init-git-annex.cmd|.sh) or
+you're going to get spurious modified files in git status. I believe the default
+is `core.autocrlf` set to true systemwide in Git for Windows. Somehow that default
+is what Git for Windows is most \"comfortable\" with, although personally I hate
+that it always \"cooks\" my newlines, so to speak. :)
+
+"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_e30fd722513b38b32e4d0f04c07a0308._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_e30fd722513b38b32e4d0f04c07a0308._comment
deleted file mode 100644
index 86cf9b922d..0000000000
--- a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_e30fd722513b38b32e4d0f04c07a0308._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="jkniiv"
- avatar="http://cdn.libravatar.org/avatar/595babb94a7609cb73c284d81467837f"
- subject="comment 4"
- date="2025-05-06T22:03:20Z"
- content="""
-@Joey: you've got email. Thanks in advance.
-"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_e30fd722513b38b32e4d0f04c07a0308._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_e30fd722513b38b32e4d0f04c07a0308._comment
new file mode 100644
index 0000000000..86cf9b922d
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_4_e30fd722513b38b32e4d0f04c07a0308._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/595babb94a7609cb73c284d81467837f"
+ subject="comment 4"
+ date="2025-05-06T22:03:20Z"
+ content="""
+@Joey: you've got email. Thanks in advance.
+"""]]

diff --git a/doc/todo/Recent_remote_activities/comment_2_d327c28a83eff83e071040c9fe79f739._comment b/doc/todo/Recent_remote_activities/comment_2_d327c28a83eff83e071040c9fe79f739._comment
new file mode 100644
index 0000000000..2dfd51c639
--- /dev/null
+++ b/doc/todo/Recent_remote_activities/comment_2_d327c28a83eff83e071040c9fe79f739._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-05-06T15:31:51Z"
+ content="""
+git grep for uuid is a good simple solution.
+
+Maybe `git-annex log --all` could be made to show all location log changes
+for all keys. Then you could just grep that for the uuid to see what
+changes have been happening to what files (if it mapped keys back to
+current filenames when possible). Implementation would be `git log`
+filtered to location log files, with `--raw` to get the diff, then
+parsing the diff.
+
+There is already code that does something very similar in
+Annex.RepoSize.diffBranchRepoSizes. And since that is already run by
+`git-annex info`, it would be cheap to pull out a last activity date
+for each repo at the same time as the repo's size, and have `git-annex
+info` display it or use it in the other ways you suggest. 
+
+The only wrinkle is that is an incremental diff since the
+last time it was called, so would not include dates for repos that
+have not changed since. So the dates would need to be cached
+somewhere.
+"""]]

diff --git a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_5_e9a78b2c8ed325ccf57c515bb162fc1d._comment b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_5_e9a78b2c8ed325ccf57c515bb162fc1d._comment
new file mode 100644
index 0000000000..776cdb167c
--- /dev/null
+++ b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_5_e9a78b2c8ed325ccf57c515bb162fc1d._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2025-05-06T15:18:51Z"
+ content="""
+It's fine to have multiple unrelated branches in a repository, I don't
+think you're doing anything wrong.
+
+Currently --historical stops once it finds one use of the key.
+I think you are wanting to find all uses by any of your branches?
+
+Maybe the right option for this use case would be a --branches that
+searches each branch for uses of the key and doesn't stop at the first hit.
+Perhaps combined with a --refspec= option that takes a wildcard that can be
+used to select which branches to search.
+"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_3_c5678f2d6c166bb68ca667a54deb429a._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_3_c5678f2d6c166bb68ca667a54deb429a._comment
new file mode 100644
index 0000000000..3c0b30fc50
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_3_c5678f2d6c166bb68ca667a54deb429a._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2025-05-06T15:15:00Z"
+ content="""
+You can email me the test repo.
+
+I expect bisection won't be of much use in tracking this down
+unfortunately.
+"""]]

diff --git a/doc/todo/Recent_remote_activities/comment_1_3ecd34337137e098e954b6c02a2c375b._comment b/doc/todo/Recent_remote_activities/comment_1_3ecd34337137e098e954b6c02a2c375b._comment
new file mode 100644
index 0000000000..e34c9d4a0f
--- /dev/null
+++ b/doc/todo/Recent_remote_activities/comment_1_3ecd34337137e098e954b6c02a2c375b._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="grepping the git-annex branch for remote activity"
+ date="2025-05-06T13:06:28Z"
+ content="""
+Apparently, `git grep` in the git-annex branch is pretty performant, so this can be used to find activity times:
+
+[[!format bash \"\"\"
+# (roughly) First date of \"activity\" in the remote
+❯ git grep $REMOTE_UUID git-annex -- '*/*.log' | sort -t: -k3 | cut -d: -f3 | cut -ds -f1 | head -n1 | xargs -ITS date -d@TS
+Mi 1. Jan 21:02:30 CET 2025
+
+# latest activity in a given remote
+❯ git grep $REMOTE_UUID git-annex -- '*/*.log' | sort -t: -k3 | cut -d: -f3 | cut -ds -f1 | tail -n1 | xargs -ITS date -d@TS
+Di 6. Mai 11:25:49 CEST 2025
+\"\"\"]]
+"""]]

diff --git a/doc/todo/Recent_remote_activities.mdwn b/doc/todo/Recent_remote_activities.mdwn
new file mode 100644
index 0000000000..15d801c260
--- /dev/null
+++ b/doc/todo/Recent_remote_activities.mdwn
@@ -0,0 +1,29 @@
+It would be great to have a way to find out when a remote was last "active" and what happened. This can help with:
+
+- knowing which remotes can safely be marked "dead", as it didn't "do" anything for the last 10 years
+- finding out what exactly a repository is or where it was, if the (auto-generated) description isn't helpful
+- double-checking if one's setup indeed does the expected, puts files where they should go, etc.
+- maybe for sorting the remotes in `git annex info` by a `last contact` time? (see also here, sorting by description would already be cool and better than sorting by UUID, which is random: https://git-annex.branchable.com/todo/Sorting_remotes_by_description_in___96__git_annex_info__96__/)
+
+For a specific file, one can already get an activity log for a specific remote with `git annex log`:
+
+[[!format  bash """
+git annex log thatfile.pdf  | grep 5091aa91-fb08-44b1-aece-7406257103f8
+# + Mon, 27 Mar 2023 21:39:07 CEST thatfile.pdf | 5091aa91-fb08-44b1-aece-7406257103f8 -- ThatRemoteName
+"""]]
+
+But that is very slow and doesn't scale at all for considering all files.
+
+There's also the `activity.log` in the git-annex branch, which AFAIK currently only logs `git annex fsck` invocation timestamps:
+
+[[!format  bash """
+git annex log thatfile.pdf  | grep 091aa91-fb08-44b1-aece-7406257103f8
+# 091aa91-fb08-44b1-aece-7406257103f8 Fsck timestamp=1743873054s
+# ...
+"""]]
+
+The commit messages on the git-annex branch don't include the remote's ID (which might be helpful but hogs disk space?), so that can't be used to inspect activity - one doesn't know who did the commit.
+
+Any ideas how this could be done?
+
+Cheers, Yann

diff --git a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_4_37e4328dbca4c499b2d3b1bb68b951e2._comment b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_4_37e4328dbca4c499b2d3b1bb68b951e2._comment
new file mode 100644
index 0000000000..8a58e289c9
--- /dev/null
+++ b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_4_37e4328dbca4c499b2d3b1bb68b951e2._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 4"
+ date="2025-05-06T07:24:51Z"
+ content="""
+Thank you for the offer. I'm a little sheepish about it though.
+
+Because I'm mindful that my, perhaps over ambition, has knock on effects. eg. is what I am doing (with unrelated branches) breaking how unusued detects unused objects?
+
+If that is the case, I'd understand being consistent and not facilitating this hubris.
+
+"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_2_5f824eb140ab826c6ca5e9d5fc6f4d3c._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_2_5f824eb140ab826c6ca5e9d5fc6f4d3c._comment
new file mode 100644
index 0000000000..a940bd25a4
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_2_5f824eb140ab826c6ca5e9d5fc6f4d3c._comment
@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/595babb94a7609cb73c284d81467837f"
+ subject="comment 2"
+ date="2025-05-06T00:14:04Z"
+ content="""
+On my end the test case is very consistent in exhibiting this problem with this particular repo
+-- as in I git clone it into half a dozen copies and then enter them one by one to run the commands
+above and, e.g., six out of six times I get the same result with the affected versions of git-annex.
+Ok, sometimes it doesn't suggest to you to run `git-annex restage` in the middle but basically
+when the availability of the annexed files change (mostly after `get` but sometimes after `drop`, too),
+git seems to think the (unlocked) files have been modified.
+
+There *is* a small red herring, though, as it turns out Git for Windows' handling of `core.autocrlf` set to
+false seems to be a bit haphazard, in which case even otherwise unaffected (i.e., older) versions
+of git-annex (or rather core git) start to unnecessarily show files as having been modified (including
+non-large files stored in plain git). But that is a separate problem which doesn't involve git-annex
+as such.
+
+Finally, the affected versions (in my tests) are the two latest released versions (with OsPath
+build flag set to true by default):
+
+  - 10.20250320-g4c8577d3a2b963d4c790124633584537a372d389
+  - 10.20250416-gb22a72cd9444071e86a46cc1eb8799e7d085b49d
+
+In contrast, version 10.20250416 built with OsPath set to false, and the pre-OsPath
+released version 10.20250115-g7a8bc19228b2e16ec86836277c4077b63667b391 seem to not
+be affected by the problem. At least that's the conclusion that I have reached by
+repeatedly running the test case a few dozen times in total (in sets of six like I
+mentioned above).
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index f0eeb7b610..f96e750319 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -4,6 +4,8 @@ git-annex (10.20250417) UNRELEASED; urgency=medium
     accessed via ssh.
   * map: Avoid looping forever with mutually recursive paths between
     repositories accessed via ssh.
+  * whereused: Fix bug that could find matches from grafts 
+    in remote git-annex branches.
 
  -- Joey Hess <id@joeyh.name>  Tue, 22 Apr 2025 14:33:26 -0400
 
diff --git a/Command/WhereUsed.hs b/Command/WhereUsed.hs
index 1a7e7033d8..28ae74585b 100644
--- a/Command/WhereUsed.hs
+++ b/Command/WhereUsed.hs
@@ -89,7 +89,7 @@ findHistorical key = do
 		[ Param ("--exclude=*/" ++ fromRef (Annex.Branch.name))
 		, Param "--glob=*"
 		-- Also search remote branches
-		, Param ("--exclude=" ++ fromRef (Annex.Branch.name))
+		, Param ("--exclude=*/" ++ fromRef (Annex.Branch.name))
 		, Param "--remotes=*"
 		-- And search tags.
 		, Param "--tags=*"
diff --git a/doc/bugs/whereused_--key_forcing_--historical._exportree__63__/comment_2_b574973835ee61fa8711831e38b77ad2._comment b/doc/bugs/whereused_--key_forcing_--historical._exportree__63__/comment_2_b574973835ee61fa8711831e38b77ad2._comment
new file mode 100644
index 0000000000..4a2fb4ff32
--- /dev/null
+++ b/doc/bugs/whereused_--key_forcing_--historical._exportree__63__/comment_2_b574973835ee61fa8711831e38b77ad2._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-05-05T18:12:16Z"
+ content="""
+I was able to reproduce the "origin/git-annex~12:export.tree" part of this
+and have fixed that, so it won't show that git-annex branch location,
+which is part of git-annex's internal bookkeeping and not something useful
+for the command to display.
+
+As to why it is not finding your file, what you show is not necessarily a
+bug. If the file `2010-08-21/042.JPG` is not staged in git, it won't be
+shown by `git-annex whereused` when run without --historical. It's easy
+enough to get into such a situation, for example you could have run a
+series of commands like this:
+
+	git-annex add 042.JPG
+	mv 042.JPG 2010-08-21/042.JPG
+	git commit -a -m foo
+
+If the file is in fact staged in git and whereused doesn't list it,
+my next guess would be that somehow it's not getting added to the
+associated files database, which is what whereused looks at.
+You can check for that with this command:
+
+	sqlite3 .git/annex/keysdb/db 'select * from associated;'| grep SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
+"""]]

diff --git a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_3_b6ed2497caf1aed67b3759221f191e51._comment b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_3_b6ed2497caf1aed67b3759221f191e51._comment
new file mode 100644
index 0000000000..7a6bbddff9
--- /dev/null
+++ b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_3_b6ed2497caf1aed67b3759221f191e51._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2025-05-05T17:46:05Z"
+ content="""
+The --historical option does look for the key in all branches, if the
+checked out branch does not contain the key.
+
+If that doesn't do what you want, it would be possible to add an option
+that only looks at branches that match a refspec you provide.
+"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_1_fe5020608317e23c95eb9ac2ed0d689d._comment b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_1_fe5020608317e23c95eb9ac2ed0d689d._comment
new file mode 100644
index 0000000000..9e6ebd4d7b
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified/comment_1_fe5020608317e23c95eb9ac2ed0d689d._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-05-05T17:34:53Z"
+ content="""
+Does your test case reproduce the problem reliably, or only sometimes?
+
+Typically when git gets into this state it's an intermittent problem based
+on timing. I want to make sure the OsPath build flag is not a red herring
+before pursuing that.
+"""]]

diff --git a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_2_12027298596113544eed90a0f0cff626._comment b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_2_12027298596113544eed90a0f0cff626._comment
new file mode 100644
index 0000000000..60a0f8d5e3
--- /dev/null
+++ b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_2_12027298596113544eed90a0f0cff626._comment
@@ -0,0 +1,56 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject="comment 2"
+ date="2025-05-05T11:13:59Z"
+ content="""
+Thank you. For your kindness, I think I owe a better explanation.
+
+It might be being a little ambitious... but I am trying to work on a git-annex where I am indexing retired internal drives. Performing a git-annex import --no-content on each setup importtree=yes remote, and then merging/fast-forwarding to a git checkout --orphan'ed branch.
+
+Key point is, now, for example, I want to find out where a file might have been duplicated.
+
+I have considered your idea of the --historical switch. But perhaps related to <https://git-annex.branchable.com/bugs/whereused_--key_forcing_--historical._exportree__63__/>, I have experienced strange behaviour, now and in the past.
+
+The following sequence might explain.
+
+```
+$ git rev-parse --abbrev-ref HEAD
+master
+$ ls
+$ # no files, because only branches with unrelated histories available
+$ git-annex whereused --key SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+$ # not unusual
+```
+
+Now with historical:
+
+```
+$ git-annex whereused --historical --key SHA256E
+-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+warning: exhaustive rename detection was skipped due to too many files.
+warning: you may want to set your diff.renameLimit variable to at least 115576 and retry the command.
+SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp ntfs,uuid=E06053EC6053C7C4~2:Program Files/Common Files/Services/verisign.bmp
+$ # this is good, but not exhaustive
+$ # plus it includes the weird to me, but perhaps explainable offset
+$ # i do prune and curate these branches after merging
+```
+
+To demonstrate that this isn't a exhaustive search, here I am following your suggestion on using git rev-list
+
+```
+$ git rev-list --objects --no-object-names --no-walk ntfs,uuid=E06053EC6053C7C4 | git annex lookupkey --ref --batch | grep SHA256E-s2702--7f79dade5c9f7c6851af225b
+e7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+$ # confirming --historical find
+$ git rev-list --objects --no-object-names --no-walk ntfs,uuid=01D20F52B11B58A0 | git annex lookupkey --ref --batch | grep SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d
+88b62259ed251638ba0140c7ea311cf2ed.bmp
+SHA256E-s2702--7f79dade5c9f7c6851af225be7d73d88b62259ed251638ba0140c7ea311cf2ed.bmp
+$ # as you can see, the only technique that sort of works is if your technique
+$ # iterated over all branches
+```
+
+Thank you again, because I do have something to work with now in any case.
+
+"""]]

diff --git a/doc/bugs/whereused_--key_forcing_--historical._exportree__63__.mdwn b/doc/bugs/whereused_--key_forcing_--historical._exportree__63__.mdwn
index 91bd7c9334..7c28fa3bef 100644
--- a/doc/bugs/whereused_--key_forcing_--historical._exportree__63__.mdwn
+++ b/doc/bugs/whereused_--key_forcing_--historical._exportree__63__.mdwn
@@ -6,7 +6,7 @@ When I run git-annex whereused --key <keyname>, nothing comes up. But if I look
 
 If I add --historical, I can see the file exists in some previous commit that I thought had been successfully merged, and moved on from. It seems like this might be related to export trees, because that keyword is also present in the output with --historical
 
-[[!format sh """
+```
 $ git-annex whereused --key SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
 $ git-annex whereused --historical --key SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG
 SHA256E-s1000013--e435522a9059bcb086b6db5fa5f05a06913266772a7931eefae2b8f7647f5f14.JPG remotes/origin/git-annex~12:export.tree/2010-08-21/042.JPG
@@ -21,7 +21,7 @@ lrwxrwxrwx 1 shaddy shaddy 201 May 20  2024 2010-08-21/042.JPG -> ../.git/annex/
 $ ls -lL 2010-08-21/042.JPG
 -r--r--r-- 1 shaddy shaddy 1000013 May 21  2024 2010-08-21/042.JPG
 $ 
-"""]]
+```
 
 My reading of the documentation is that the file being present in the local annex shouldn't require the --historical argument, which is much slower.
 

diff --git a/doc/special_remotes/httpalso/comment_9_f98b7efe70190850044c6da60f79092d._comment b/doc/special_remotes/httpalso/comment_9_f98b7efe70190850044c6da60f79092d._comment
new file mode 100644
index 0000000000..d9a2484283
--- /dev/null
+++ b/doc/special_remotes/httpalso/comment_9_f98b7efe70190850044c6da60f79092d._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="Basile.Pinsard"
+ avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
+ subject="Setup dirhash parameter for httpalso to avoid hammering server"
+ date="2025-05-02T17:53:53Z"
+ content="""
+Hi @Joey,
+I was wondering if it would be possible to setup the dirhash format for the special remote.
+
+We push data to a datalad ria-store through ssh that gets RO accessed through a httpalso remote.
+However, I observe that get operations try different directory hashing schema before hitting the right one that datalad ORA remote uses.
+This is also the case when doing repo-wide `fsck` in recurring tests of the dataset. 
+All of that is doubling the number of http request, and could in some setups trigger fail2ban-type mechanisms at network or server levels.
+If there was a parameter that could be set on the httpalso to directly use the right URLs, that would be great.
+
+Thanks!
+"""]]

diff --git a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_1_865ddb8dcfdfc9ed8f2898816be8fbb1._comment b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_1_865ddb8dcfdfc9ed8f2898816be8fbb1._comment
new file mode 100644
index 0000000000..f58608a5e7
--- /dev/null
+++ b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout/comment_1_865ddb8dcfdfc9ed8f2898816be8fbb1._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="kyle"
+ avatar="http://cdn.libravatar.org/avatar/7d6e85cde1422ad60607c87fa87c63f3"
+ subject="re: finding key in specific branches"
+ date="2025-05-01T03:51:27Z"
+ content="""
+> get git-annex whereused --key to act on one or more other branches
+> than the checked-out one
+
+The `--historical` flag of `whereused` leads to a wider search,
+including of other branches but also other things, like the current
+branch's history and the reflog.
+
+I'm guessing you're after more specific control.
+
+If I want to know when a key occurred in a particular branch, I
+usually do something like
+
+```
+$ git log -p -S $KEY $BRANCH
+```
+
+To know whether a particular key is in the *tip* of a particular
+branch (or of some subset of branches), one way would be
+
+```
+$ git rev-list --objects --no-object-names --no-walk $BRANCH | \
+  git annex lookupkey --ref --batch | \
+  grep $KEY
+```
+
+Perhaps there are more streamlined ways to get to that information,
+though.
+"""]]

diff --git a/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_8_fc8958af2a03a2f3b8ad83a276e1eb34._comment b/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_8_fc8958af2a03a2f3b8ad83a276e1eb34._comment
new file mode 100644
index 0000000000..c97fece171
--- /dev/null
+++ b/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_8_fc8958af2a03a2f3b8ad83a276e1eb34._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="msz"
+ avatar="http://cdn.libravatar.org/avatar/6e8b88e7c70d86f4cfd27d450958aed4"
+ subject="Thank you for implementing"
+ date="2025-04-29T17:00:36Z"
+ content="""
+Thank you! I just tried the mask remote with our forgejo-aneksajo instance with HTTPS push and the mask remote works just as intended. This will be very useful!
+"""]]

diff --git a/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified.mdwn b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified.mdwn
new file mode 100644
index 0000000000..3a86583375
--- /dev/null
+++ b/doc/bugs/OsPath_bld_of_g-a_shows_files_needlessly_modified.mdwn
@@ -0,0 +1,526 @@
+---
+title: (Windows) OsPath build of git-annex shows files needlessly modified in git status
+---
+### Please describe the problem.
+
+I've found some small undesirable behaviour or some kind of regression with the two recent releases
+of git-annex employing the OsPath build flag / code path on Windows (NTFS). The problem is that
+`git status` sometimes shows recently `get` or `drop`'ed annexed files as modified (when in fact
+they are really not) and no amount of `git restore` commands issued will rectify the situation
+when it happens. However, by disabling the `ospath` flag in `stack.yaml` and then rebuilding
+git-annex the problem seems to go away.
+
+I'm not sure I can fabricate a clean test case by just by conjuring up a few commands, so I have
+made a reasonably small version of my repo once again by employing the tip [[tips/splitting_a_repository]].
+It has only a dozen or so rather non-personal files related to a git-annex bug report from about four
+years back. I can make it available to Joey via email, if so desired. Due to tiny, remaining
+privacy reasons (it includes metadata *not* data as such and the files are really of no consequence
+to anybody even if made public), I'd still prefer to not link the tarball here.
+
+### What steps will reproduce the problem?
+
+The following steps are in Git Bash.
+
+[[!format sh """
+jkniiv@AINESIS MINGW64 ~
+$ cd /e/git-annex-tests/test-ospath-regression/
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression
+$ git annex version | head -2
+git-annex version: 10.20250416-gb22a72cd9444071e86a46cc1eb8799e7d085b49d
+build flags: Assistant Webapp Pairing TorrentParser Servant Benchmark Feeds Testsuite S3 WebDAV
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression
+$ ls
+'Sm1@split.tar.xz'
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression
+$ tar -xf Sm1\@split.tar.xz
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression
+$ du -hs Sm1\@split
+771M    Sm1@split
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression
+$ ls
+'Sm1@split'/  'Sm1@split.tar.xz'
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression
+$ git clone Sm1\@split Sm2
+Cloning into 'Sm2'...
+done.
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression
+$ cd Sm2/
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2 (adjusted/master(unlocked))
+$ ls
+Ylläpito/  _scripts/
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2 (adjusted/master(unlocked))
+$ cd _scripts/
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2/_scripts (adjusted/master(unlocked))
+$ cat init-git-annex.cmd
+git config annex.thin true
+git config annex.backend BLAKE2B160E
+git config annex.largefiles "largerthan=1megabytes"
+git config annex.maxextensionlength 8
+git config core.autocrlf false
+git config receive.denycurrentbranch warn
+git config merge.renames true
+git config merge.directoryRenames false
+git annex init "Sm clone (split version)"
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2/_scripts (adjusted/master(unlocked))
+$ cp init-git-annex.cmd init-git-annex.sh
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2/_scripts (adjusted/master(unlocked))
+$ dos2unix init-git-annex.sh
+dos2unix: converting file init-git-annex.sh to Unix format...
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2/_scripts (adjusted/master(unlocked))
+$ nano init-git-annex.sh
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2/_scripts (adjusted/master(unlocked))
+$ cat init-git-annex.sh
+git config annex.thin true
+git config annex.backend BLAKE2B160E
+git config annex.largefiles "largerthan=1megabytes"
+git config annex.maxextensionlength 8
+git config core.autocrlf false
+git config receive.denycurrentbranch warn
+git config merge.renames true
+git config merge.directoryRenames false
+git annex init "Sm2"
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2/_scripts (adjusted/master(unlocked))
+$ git status
+On branch adjusted/master(unlocked)
+Your branch is up to date with 'origin/adjusted/master(unlocked)'.
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+        init-git-annex.sh
+
+nothing added to commit but untracked files present (use "git add" to track)
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2/_scripts (adjusted/master(unlocked))
+$ sh -x init-git-annex.sh
++ git config annex.thin true
++ git config annex.backend BLAKE2B160E
++ git config annex.largefiles largerthan=1megabytes
++ git config annex.maxextensionlength 8
++ git config core.autocrlf false
++ git config receive.denycurrentbranch warn
++ git config merge.renames true
++ git config merge.directoryRenames false
++ git annex init Sm2
+init Sm2
+  Detected a filesystem without fifo support.
+
+  Disabling ssh connection caching.
+
+  Detected a crippled filesystem.
+ok
+(recording state in git...)
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2/_scripts (adjusted/master(unlocked))
+$ cd ..
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2 (adjusted/master(unlocked))
+$ ls
+Ylläpito/  _scripts/
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2 (adjusted/master(unlocked))
+$ git annex info
+trusted repositories: 0
+semitrusted repositories: 8
+        00000000-0000-0000-0000-000000000001 -- web
+        00000000-0000-0000-0000-000000000002 -- bittorrent
+        06b5457f-a76e-4e44-a3d6-7a06cdda62a8 -- Jibun.Safe1812-klooni
+        163fd60d-2d8a-4ef5-9c8c-d6b6e3c9d51c -- Sm2 [here]
+        4fd98ae2-42e3-4b93-8b81-0316dbf38169 -- Jibun.Safe1812
+        5e431ba8-1fc6-4d99-b831-8c3571b57272 -- Sm clone (split version) [origin]
+        88035634-8cb4-4e7f-b482-398bd9e2b9ab -- Sm clone (source)
+        c1ba110c-97eb-4e3c-989e-afb9cb4f75a6 -- Jibun.Safe2504p (S: > P:)
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 74.56 gigabytes (+100 megabytes reserved)
+local annex keys: 0
+local annex size: 0 bytes
+annexed files in working tree: 6
+size of annexed files in working tree: 805.75 megabytes
+combined annex size of all repositories: 805.75 megabytes
+annex sizes of repositories:
+        805.75 MB: 5e431ba8-1fc6-4d99-b831-8c3571b57272 -- Sm clone (split version) [origin]
+backend usage:
+        BLAKE2B160E: 6
+bloom filter size: 32 mebibytes (0% full)
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2 (adjusted/master(unlocked))
+$ git annex get .
+get "Yll\303\244pito/FileSpy/git-annex-fsck.9BEAE03792B9FAFB-01-01.mrimg.txt" (from origin...)
+(checksum...) ok
+get "Yll\303\244pito/FileSpy/git-annex-fsck.9BEAE03792B9FAFB-01-01.mrimg.utf8.txt" (from origin...)
+ok
+get "Yll\303\244pito/FileSpy/git-annex-sync---content-of.9BEAE03792B9FAFB-01-01.mrimg.txt" (from origin...)
+ok
+get "Yll\303\244pito/FileSpy/git-annex-sync---content-of.9BEAE03792B9FAFB-01-01.mrimg.utf8.txt" (from origin...)
+ok
+get "Yll\303\244pito/FileSpy/git-annex-sync---content-of.9BEAE03792B9FAFB-01-01.mrimg~2.txt" (from origin...)
+ok
+get "Yll\303\244pito/FileSpy/git-annex-sync---content-of.9BEAE03792B9FAFB-01-01.mrimg~2.utf8.csv" (from origin...)
+ok
+(recording state in git...)
+
+jkniiv@AINESIS MINGW64 /e/git-annex-tests/test-ospath-regression/Sm2 (adjusted/master(unlocked))
+$ git status
+On branch adjusted/master(unlocked)
+Your branch is up to date with 'origin/adjusted/master(unlocked)'.
+
+Changes not staged for commit:
+  (use "git add <file>..." to update what will be committed)
+  (use "git restore <file>..." to discard changes in working directory)
+        modified:   "Yll\303\244pito/FileSpy/git-annex-fsck.9BEAE03792B9FAFB-01-01.mrimg.txt"
+        modified:   "Yll\303\244pito/FileSpy/git-annex-fsck.9BEAE03792B9FAFB-01-01.mrimg.utf8.txt"
+        modified:   "Yll\303\244pito/FileSpy/git-annex-sync---content-of.9BEAE03792B9FAFB-01-01.mrimg.txt"
+        modified:   "Yll\303\244pito/FileSpy/git-annex-sync---content-of.9BEAE03792B9FAFB-01-01.mrimg.utf8.txt"
+        modified:   "Yll\303\244pito/FileSpy/git-annex-sync---content-of.9BEAE03792B9FAFB-01-01.mrimg~2.txt"
+        modified:   "Yll\303\244pito/FileSpy/git-annex-sync---content-of.9BEAE03792B9FAFB-01-01.mrimg~2.utf8.csv"
+
+Untracked files:
+  (use "git add <file>..." to include in what will be committed)
+        _scripts/init-git-annex.sh

(Diff truncated)

diff --git a/doc/forum/Scalability_Issues.mdwn b/doc/forum/Scalability_Issues.mdwn
new file mode 100644
index 0000000000..d9f371e184
--- /dev/null
+++ b/doc/forum/Scalability_Issues.mdwn
@@ -0,0 +1,66 @@
+# Scalability Issues
+
+I am struggling with very slow operations in my cluster setup and looking for some advice.
+
+## Setup
+
+My repository contains **24 million files** with a total of **2.3 terabyte**.
+The files are divided into several sub folders so the file count per directory is below 20k.
+I am using the git-annex cluster setup with **one gateway** and **16 nodes**.
+
+The gateway repository stores a copy of all files.
+The distribution of the files across the 16 nodes should be random but deterministic. Therefore, I want to use the filehash property (SHA-256) and store all files starting with one of the 16 characters `0-f` on one of the 16 nodes. For example, `node-01` stores all files starting with filehash `0...` and `node-16` stores all files starting with filehash `f...`.
+
+Since I did not find an immediate preferred content expression for this special distribution method, I decided to add the hash as metadata to every annexed file using a pre-commit hook.
+Inside the git-annex config, I define for each node that it only stores files with one of the characters.
+
+```
+wanted node-01 = metadata=hash=0*
+wanted node-02 = metadata=hash=1*
+...
+wanted node-16 = metadata=hash=f*
+```
+
+## Issues
+
+### Adding files
+While adding more and more files with git-annex, I noticed that `(recording state in git...)` takes very long and my whole memory (8GB) is used by git-annex.
+Therefore, increasing the `annex.queuesize` at the expense of more memory is not possible [ [1] ](https://git-annex.branchable.com/scalability/).
+Is there anything else to adjust? Why does it use so much RAM? Is my number of files out of scope for git?
+
+### Commiting files
+Furthermore, I use the following `pre-commit-annex` hook to add the filehash as metadata to the files.
+However, it takes almost one second for each file to add the metadata.
+I am trying to adjust the script to support batches as well but maybe there is a different way to distribute the files across nodes by the filehash?
+
+```
+#!/bin/bash
+
+if git rev-parse --verify HEAD >/dev/null 2>&1; then
+	against="HEAD"
+else
+	# Initial commit: diff against an empty tree object
+	against="4b825dc642cb6eb9a060e54bf8d69288fbee4904"
+fi
+
+process() {
+	file_hash=$(readlink "$file_path" | tail -c 65)
+	if \[[ -n "$file_hash" ]];  then
+		git -c annex.alwayscommit=false annex metadata --set "hash=$file_hash" --quiet -- "$file_path"
+	fi
+}
+
+if \[[ -n "$*" ]];  then
+	for file_path in "$@"; do
+		process "$file_path"
+	done
+else
+	git diff-index -z --name-only --cached $against | sed 's/\x00/\n/g' | while read file_path; do
+		process "$file_path"
+	done
+fi
+```
+
+[1] [https://git-annex.branchable.com/scalability/](https://git-annex.branchable.com/scalability/)
+
+I would be glad for any feedback :)

diff --git a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout.mdwn b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout.mdwn
index 045e831c0b..cb0ce25475 100644
--- a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout.mdwn
+++ b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout.mdwn
@@ -1 +1 @@
-Not sure if this is a feature request... is it possible to get git-annex whereused --key to act on one or more other branches than the checkout one... obviously without having to check each individual one out?
+Not sure if this is a feature request... is it possible to get git-annex whereused --key to act on one or more other branches than the checked-out one... obviously without having to check each individual one out?

diff --git a/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout.mdwn b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout.mdwn
new file mode 100644
index 0000000000..045e831c0b
--- /dev/null
+++ b/doc/forum/whereused__58___--key_other_branches_w__47__o_checkout.mdwn
@@ -0,0 +1 @@
+Not sure if this is a feature request... is it possible to get git-annex whereused --key to act on one or more other branches than the checkout one... obviously without having to check each individual one out?

diff --git a/doc/forum/remotes__47__repo__47__HEAD_-__62___repo__47__master.mdwn b/doc/forum/remotes__47__repo__47__HEAD_-__62___repo__47__master.mdwn
new file mode 100644
index 0000000000..38f5cd1063
--- /dev/null
+++ b/doc/forum/remotes__47__repo__47__HEAD_-__62___repo__47__master.mdwn
@@ -0,0 +1,7 @@
+In one of my repositories (say `REPO1`) I have a line in `git branch --all`
+
+    remotes/REPO2/HEAD -> REPO2/master
+
+`REPO2` refers to the name of another remote.
+
+How did I do that?

diff --git a/doc/tips/cloning_a_repository_privately/comment_3_99a3786dbea66cd49dc718bafbf829df._comment b/doc/tips/cloning_a_repository_privately/comment_3_99a3786dbea66cd49dc718bafbf829df._comment
new file mode 100644
index 0000000000..f3f132e10e
--- /dev/null
+++ b/doc/tips/cloning_a_repository_privately/comment_3_99a3786dbea66cd49dc718bafbf829df._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
+ nickname="beryllium"
+ avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
+ subject=""Buyer's remorse""
+ date="2025-04-28T05:53:47Z"
+ content="""
+If you initialise a remote as private, and then change your mind, is there anyway to promote that remote and it's metadata back to a public scoping?
+
+"""]]

diff --git a/doc/install/Linux_standalone/comment_7_9a6a093d12f5a2cfbec7fdc95f19d2e8._comment b/doc/install/Linux_standalone/comment_7_9a6a093d12f5a2cfbec7fdc95f19d2e8._comment
new file mode 100644
index 0000000000..d37eb6d7e8
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_7_9a6a093d12f5a2cfbec7fdc95f19d2e8._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="standalone builds apparently not deployed"
+ date="2025-04-24T15:23:47Z"
+ content="""
+Yup:
+
+[[!format  bash \"\"\"
+❯ git annex info git-annex/linux/current/git-annex-standalone-amd64.tar.gz
+file: git-annex/linux/current/git-annex-standalone-amd64.tar.gz
+size: 62.24 megabytes
+key: SHA256E-s62243866--e127f7cbb28d116cb34a22321b3a8db469d73174b23869c122d9425066729ea5.tar.gz
+present: false
+❯ git annex whereis git-annex/linux/current/git-annex-standalone-amd64.tar.gz
+whereis git-annex/linux/current/git-annex-standalone-amd64.tar.gz (1 copy) 
+  	4f2108b9-5561-40a1-8923-b0b683b3b898 -- joey@kite:~/lib/downloads
+ok
+\"\"\"]]
+"""]]

diff --git a/doc/install/Linux_standalone/comment_6_feb864df2afd91f6a7e96479bf7da806._comment b/doc/install/Linux_standalone/comment_6_feb864df2afd91f6a7e96479bf7da806._comment
new file mode 100644
index 0000000000..d050bf7719
--- /dev/null
+++ b/doc/install/Linux_standalone/comment_6_feb864df2afd91f6a7e96479bf7da806._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="Basile.Pinsard"
+ avatar="http://cdn.libravatar.org/avatar/87e1f73acf277ad0337b90fc0253c62e"
+ subject="comment 6"
+ date="2025-04-24T14:27:33Z"
+ content="""
+https://downloads.kitenet.net/git-annex/linux/current only contains .sig files. so the link above are broken. 
+"""]]

diff --git a/doc/git-annex-config/comment_6_2ac1f9037c32fbe45e5f51bf846cb94a._comment b/doc/git-annex-config/comment_6_2ac1f9037c32fbe45e5f51bf846cb94a._comment
new file mode 100644
index 0000000000..e86a2c56ad
--- /dev/null
+++ b/doc/git-annex-config/comment_6_2ac1f9037c32fbe45e5f51bf846cb94a._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="matteo@4122eaeed50d58332e6ae9e6ba7237fe81294399"
+ nickname="matteo"
+ avatar="http://cdn.libravatar.org/avatar/b113a0f7867c398c5e9c24646f8495b8"
+ subject="Disabling "synced" branches"
+ date="2025-04-24T02:34:59Z"
+ content="""
+Is there any option/configuration to disable the creation and use of \"synced/*\" branches on `git annex sync`?
+
+I have a simple \"centralised\" setup where local clones push/pull from a single remote bare repository, so I don't see the benefit of using \"synced/*\" branches. They mostly just add noise in whichever git GUI I use.
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index 71168b39d3..f0eeb7b610 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -2,6 +2,8 @@ git-annex (10.20250417) UNRELEASED; urgency=medium
 
   * map: Fix buggy handling of remotes that are bare git repositories
     accessed via ssh.
+  * map: Avoid looping forever with mutually recursive paths between
+    repositories accessed via ssh.
 
  -- Joey Hess <id@joeyh.name>  Tue, 22 Apr 2025 14:33:26 -0400
 
diff --git a/Git/Construct.hs b/Git/Construct.hs
index 3d37e137c6..7d21c92478 100644
--- a/Git/Construct.hs
+++ b/Git/Construct.hs
@@ -130,7 +130,7 @@ localToUrl reference r
 				[ s
 				, "//"
 				, auth
-				, fromOsPath $
+				, fromOsPath $ simplifyPath $
 					toOsPath referencepath </> repoPath r
 				]
 			in r { location = Url $ fromJust $ parseURIPortable absurl }
diff --git a/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_1_cb67146caf6abb5382c6a4c389b76487._comment b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_1_cb67146caf6abb5382c6a4c389b76487._comment
index 2e125ab3c4..a437a22915 100644
--- a/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_1_cb67146caf6abb5382c6a4c389b76487._comment
+++ b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_1_cb67146caf6abb5382c6a4c389b76487._comment
@@ -15,20 +15,6 @@ Produced what I think is the same bug, or related, though without the looping:
 Where foo is a remote accessed via ssh, which happens to be on the same host and parent directory
 as the repo I ran map in, and itself has a remote named foo that has an url of "../foo.git"
 
-Changing the remote to be named foox with url "../foox", and 
-with the bare remote now at "../foox.git", I started to see some looping too,
-though it didn't loop forever:
-
-	map . ok
-	map origin (sshing...)
-	ok
-	map foox (sshing...)
-	ok
-	map origin (sshing...)
-	ok
-	map foox (sshing...)
-	ok
-
 One or both problems are caused by `map` using Git.Construct.fromRemotes
 on the git config that is has gotten by sshing to the remote and listing its config.
 Git.Construct really is written to operate on local repos, and fromRemotes
diff --git a/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_3_b86ad77f74b33a28963bde0850df7aa8._comment b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_3_b86ad77f74b33a28963bde0850df7aa8._comment
new file mode 100644
index 0000000000..6c0e7bfecf
--- /dev/null
+++ b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_3_b86ad77f74b33a28963bde0850df7aa8._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2025-04-22T19:42:40Z"
+ content="""
+Ok, I added path normalization and that fixed the infinite loop that I saw.
+
+I'm not 100% sure that it fixed the loop you saw though. Please test a
+daily build.
+"""]]

diff --git a/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_2_ef9ebd5d955ca42bc882d8d7d3531918._comment b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_2_ef9ebd5d955ca42bc882d8d7d3531918._comment
new file mode 100644
index 0000000000..049bf70fe3
--- /dev/null
+++ b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_2_ef9ebd5d955ca42bc882d8d7d3531918._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2025-04-22T19:27:43Z"
+ content="""
+Put in some fixes which have solved the ".git.git" problem.
+
+Also though I reproduced the infinite loop just now, and it still is a problem
+after my fixes. I had a repo with a remote foo, accessed over ssh. That remote
+itself had a local remote with path "../foo.git". And foo.git had a remote with
+path "../foo"
+
+Resulting in a loop like:
+	
+	ssh://localhost/~/tmp/foo/../foo.git/../foo/../foo.git/../foo/../foo.git/../foo/..
+
+Making the foo.git's remote have a path like "/home/joey/tmp/foo"
+avoids the problem.
+
+I think that the fix for this is going to need to involve path normalization.
+Because this could happen with 2 git repos, that don't have git-annex uuids.
+So it needs to be able to figure out that "foo/../foo.git" is the same as
+"foo/../foo.git/../foo/../foo.git"
+"""]]

diff --git a/doc/todo/map__58___add_--json/comment_1_b8520df95bb2cbf2570ee48cd2df9b06._comment b/doc/todo/map__58___add_--json/comment_1_b8520df95bb2cbf2570ee48cd2df9b06._comment
new file mode 100644
index 0000000000..bc77346b55
--- /dev/null
+++ b/doc/todo/map__58___add_--json/comment_1_b8520df95bb2cbf2570ee48cd2df9b06._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-04-22T17:19:05Z"
+ content="""
+Adding --json to `map` would be a useful thing to do.
+
+Conceptually, we have here a directed graph (cyclic) with named edges 
+(remote names) and nodes (repository uuids or urls). Fitting a cyclic graph
+into json probably needs something not unlike the graphviz output, and
+also as implemented `map` doesn't actually build the graph internally.
+
+So I envision a json output something like a list of nodes, where each node
+has a field for uuid (omitted for non-annex git repos), a field 
+for url, and a field containing a list of its remotes. With each json
+object in the remotes list having a remote name, a uuid (for annex repos),
+and an url.
+
+As for how well it might fit the needs of your project, some thoughts:
+
+* `map` is able to spider out to remotes of remotes, but that's as far as
+  it can go, since it only queries the `git config` of remote repositories,
+  and does not run itself recursively on other hosts. Which can only get so
+  far, but is a reasonable limitation for it. Often sshing into a remote
+  host to run map recursively would be blocked for security reasons anyway.
+  With --json output, you could run `map` on several hosts and combine them
+  easily enough.
+* `map` does not currently show connections to special remotes, which maybe you
+  would need. This would be easy to do for special remotes of the local
+  repository, but it seems like it would actually be pretty hard to do for
+  special remotes of a remote repository.
+"""]]

diff --git a/doc/todo/p2phttp__58___listen_on_unix_domain_sockets/comment_1_f112ad460a6cdc1551839a5315dd8025._comment b/doc/todo/p2phttp__58___listen_on_unix_domain_sockets/comment_1_f112ad460a6cdc1551839a5315dd8025._comment
new file mode 100644
index 0000000000..a35f8ac00c
--- /dev/null
+++ b/doc/todo/p2phttp__58___listen_on_unix_domain_sockets/comment_1_f112ad460a6cdc1551839a5315dd8025._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-04-21T17:02:34Z"
+ content="""
+That might be hard to implement, since it uses servant to do the http
+serving and that probably does not have a way to listen to a unix domain
+socket.
+
+Is this needed any more since p2phttp does support serving multiple
+repositories?
+"""]]

diff --git a/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_1_cb67146caf6abb5382c6a4c389b76487._comment b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_1_cb67146caf6abb5382c6a4c389b76487._comment
new file mode 100644
index 0000000000..2e125ab3c4
--- /dev/null
+++ b/doc/bugs/map_goes_into_a_loop_for_a_bare_remote_/comment_1_cb67146caf6abb5382c6a4c389b76487._comment
@@ -0,0 +1,39 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-04-21T16:14:49Z"
+ content="""
+Produced what I think is the same bug, or related, though without the looping:
+
+	map foo (sshing...)
+	[2025-04-21 12:33:47.241024518] (Utility.Process) process [1709431] read: ssh ["localhost","-S",".git/annex/ssh/localhost","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","sh -c 'cd ~ && if ! cd '\"'\"'tmp/foo/../foo.git.git'\"'\"' 2>/dev/null; then cd '\"'\"'tmp/foo/../foo.git.git'\"'\"'.git; fi && git config --null --list'"
+	sh: 1: cd: can't cd to tmp/foo/../foo.git.git.git
+	(sshing...)
+	[2025-04-21 12:33:47.249055766] (Utility.Process) process [1709434] read: ssh ["localhost","-S",".git/annex/ssh/localhost","-o","ControlMaster=auto","-o","ControlPersist=yes","-n","-T","git-annex-shell 'configlist' '/~/tmp/foo/../foo.git.git' '--debug'"]
+	git-annex: failed to read git config of git repository in darkstar on /~/tmp/foo/../foo.git.git; perhaps this repository is not set up correctly or has moved
+
+Where foo is a remote accessed via ssh, which happens to be on the same host and parent directory
+as the repo I ran map in, and itself has a remote named foo that has an url of "../foo.git"
+
+Changing the remote to be named foox with url "../foox", and 
+with the bare remote now at "../foox.git", I started to see some looping too,
+though it didn't loop forever:
+
+	map . ok
+	map origin (sshing...)
+	ok
+	map foox (sshing...)
+	ok
+	map origin (sshing...)
+	ok
+	map foox (sshing...)
+	ok
+
+One or both problems are caused by `map` using Git.Construct.fromRemotes
+on the git config that is has gotten by sshing to the remote and listing its config.
+Git.Construct really is written to operate on local repos, and fromRemotes
+ends up calling Git.Construct.fromPath, which checks doesDirectoryExist ... locally.
+
+That is just not ever going to work correctly and map will need to use something else
+to get the paths to the remotes.
+""]]

diff --git a/doc/todo/git-remote-annex.mdwn b/doc/todo/git-remote-annex.mdwn
index f492858f1f..6c5f3a19f9 100644
--- a/doc/todo/git-remote-annex.mdwn
+++ b/doc/todo/git-remote-annex.mdwn
@@ -6,6 +6,6 @@ It will be a safer implementation, will support incremental pushes, and
 will be available to users who don't use datalad. 
 --[[Joey]]
 
-> [[done!]] --[[Joey]]
+> [[done]]! --[[Joey]]
 
 See also: [[git-remote-annex_web_special_remote_support]]

diff --git a/doc/todo/migration_to_VURL_by_default.mdwn b/doc/todo/migration_to_VURL_by_default.mdwn
index 7d1c4b4385..326967b90d 100644
--- a/doc/todo/migration_to_VURL_by_default.mdwn
+++ b/doc/todo/migration_to_VURL_by_default.mdwn
@@ -14,6 +14,11 @@ eventually. Could be a fsck warning about URL keys, at some point after
 transferring the content between repositories that it's not possible to
 verify it.
 
+> This would need a way to migrate from URL key to VURL key.
+> Currently, `git-annex migrate` of an URL key defaults to using the
+> default hashing backend. And adding `--backend=VURL` does not work.
+> --[[Joey]]
+
 Of course if users want to continue to use their existing URL keys and 
 not be able to verify content, that's fine. Users can also choose to use 
 WORM keys if they really want to. 
@@ -27,3 +32,14 @@ configuration of which kind of keys addurl uses, once VURL is the default.
 > generates an URL key. If that is changed to generate a VURL key, then
 > it might break some workflow, particularly one where an url was
 > registered as an URL key and is now being unregistered.
+> 
+> > Also `git-annex registerurl`, if it generated a VURL key, would not be 
+> > able to register an equivilant key for that VURL key, because it does
+> > not have the content of the url available. This leads me to think 
+> > that it's not possible to have registerurl usefully support generating
+> > VURL keys. (Registering one without an equivilant key would make no hash
+> > verification be done, so no better than an URL key.)
+> > 
+> > But, I don't think that registerurl/unregisterurl continuing to
+> > generate URL keys is a big problem, it should not block making VURL
+> > the default in places where it can be default. --[[Joey]]

diff --git a/doc/bugs/VURL_verification_failure_on_first_download/comment_3_c637abff05a7ae9e7cad83b8b623c09b._comment b/doc/bugs/VURL_verification_failure_on_first_download/comment_3_c637abff05a7ae9e7cad83b8b623c09b._comment
new file mode 100644
index 0000000000..4637a9b563
--- /dev/null
+++ b/doc/bugs/VURL_verification_failure_on_first_download/comment_3_c637abff05a7ae9e7cad83b8b623c09b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2025-04-21T15:50:09Z"
+ content="""
+Note that the compute special remote handles its VURL keys by calling
+addEquivilantKey when it's computed a new value.
+
+I do think this belongs in the special remote, so if anything what's needed
+is an extension to the external special remote protocol, or a plumbing
+command.
+"""]]

diff --git a/doc/news/version_10.20250416/comment_3_9a9b7aa33311822ab38c00ca7477668b._comment b/doc/news/version_10.20250416/comment_3_9a9b7aa33311822ab38c00ca7477668b._comment
new file mode 100644
index 0000000000..6c4d462cee
--- /dev/null
+++ b/doc/news/version_10.20250416/comment_3_9a9b7aa33311822ab38c00ca7477668b._comment
@@ -0,0 +1,20 @@
+[[!comment format=mdwn
+ username="liam"
+ avatar="http://cdn.libravatar.org/avatar/5cb416d010c1d3f0ca677dd7f6c822ea"
+ subject="Fetch from good repo to fix uuid.log issue"
+ date="2025-04-20T12:32:31Z"
+ content="""
+Hi,
+
+So to resolve the .DS_Store issue, I just had to go into the .git repo and remove all the .DS_Store files that MacOS littered around.
+
+To fix the repo itself, I ended up doing a `git fetch goodremote` and this seems to have fixed the issue.
+I can now run `git annex info` again without a problem.
+
+The weird thing is, it was complaining about `uuid.log`, however, when running `git show git-annex:uuid.log` I was getting the same output on both repos.
+It's not clear what went wrong. Maybe corruption but `git fsck` never showed an issue. Fetching from a good repo seems to have fixed it.
+
+Hopefully this helps if anyone has a similar problem.
+
+Liam
+"""]]

diff --git a/doc/news/version_10.20250416/comment_2_88fc9ef91f9830f67b7658232a727ac4._comment b/doc/news/version_10.20250416/comment_2_88fc9ef91f9830f67b7658232a727ac4._comment
new file mode 100644
index 0000000000..54e94ec2bf
--- /dev/null
+++ b/doc/news/version_10.20250416/comment_2_88fc9ef91f9830f67b7658232a727ac4._comment
@@ -0,0 +1,34 @@
+[[!comment format=mdwn
+ username="liam"
+ avatar="http://cdn.libravatar.org/avatar/5cb416d010c1d3f0ca677dd7f6c822ea"
+ subject="Repairing repositories on MacOS"
+ date="2025-04-20T02:49:48Z"
+ content="""
+Hi,
+
+As follow on from the above, I'm trying to repair the repo using the built-in tool from here: [[https://git-annex.branchable.com/git-annex-repair/]]
+However, it seems to have problems on MacOS.
+
+```
+$ git annex repair
+repair  Running git fsck ...                                                                                                                                                                                                                         
+Fsck found no problems. Checking for broken branches.                                                                                                                                                                                                
+fatal: ambiguous argument 'refs/.DS_Store': unknown revision or path not in the working tree.                                                                                                                                                        
+Use '--' to separate paths from revisions, like this:                                                                                                                                                                                                
+'git <command> [<revision>...] -- [<file>...]'                                                                                                                                                                                                       
+fatal: ambiguous argument 'refs/heads/.DS_Store': unknown revision or path not in the working tree.                                                                                                                                                  
+Use '--' to separate paths from revisions, like this:                                                                                                                                                                                                
+'git <command> [<revision>...] -- [<file>...]'                                                                                                                                                                                                       
+^C
+```
+
+Somethings gone quite wrong if those .DS_Store files are showing up there.
+
+I'd love to dig into the source for git-annex but I don't know Haskell...
+Maybe this is a sign I should learn it?
+
+The `uuid.log` problem in my previous post seems to have a bit of documentation here: [[https://git-annex.branchable.com/internals/]]
+Maybe it has something to do with a previously failed clone attempt? I will dig some more tomorrow.
+
+Liam
+"""]]

diff --git a/doc/news/version_10.20250416/comment_1_910c84a8ef1d6aed657be912dd68ffbd._comment b/doc/news/version_10.20250416/comment_1_910c84a8ef1d6aed657be912dd68ffbd._comment
new file mode 100644
index 0000000000..db0be8c0b9
--- /dev/null
+++ b/doc/news/version_10.20250416/comment_1_910c84a8ef1d6aed657be912dd68ffbd._comment
@@ -0,0 +1,86 @@
+[[!comment format=mdwn
+ username="liam"
+ avatar="http://cdn.libravatar.org/avatar/5cb416d010c1d3f0ca677dd7f6c822ea"
+ subject="Corruption? invalid object for uuid.log"
+ date="2025-04-20T02:32:45Z"
+ content="""
+Hello,
+
+I just installed this version (10.20250416) this afternoon.
+Now I have the following issue:
+
+```
+$ git annex info
+(recording state in git...)
+error: invalid object 100644 f83a2e4115f14218f574058d3b3ccf72e9cfe677 for 'uuid.log'
+fatal: git-write-tree: error building trees
+git-annex: failed to read sha from git write-tree
+```
+
+and again with --verbose and --debug
+
+```
+git annex info --verbose --debug
+[2025-04-20 04:27:23.998527] (Utility.Process) process [12752] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"git-annex\"]
+[2025-04-20 04:27:24.042056] (Utility.Process) process [12752] done ExitSuccess
+[2025-04-20 04:27:24.042331] (Utility.Process) process [12753] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2025-04-20 04:27:24.046759] (Utility.Process) process [12753] done ExitSuccess
+[2025-04-20 04:27:24.051021] (Utility.Process) process [12754] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"hash-object\",\"-w\",\"--no-filters\",\"--stdin-paths\"]
+[2025-04-20 04:27:24.051495] (Utility.Process) process [12755] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"update-index\",\"-z\",\"--index-info\"]
+[2025-04-20 04:27:24.265152] (Utility.Process) process [12755] done ExitSuccess
+[2025-04-20 04:27:24.265928] (Annex.Branch) read transitions.log
+[2025-04-20 04:27:24.266808] (Utility.Process) process [12756] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch\"]
+(recording state in git...)
+[2025-04-20 04:27:24.278685] (Utility.Process) process [12757] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"write-tree\"]
+error: invalid object 100644 f83a2e4115f14218f574058d3b3ccf72e9cfe677 for 'uuid.log'
+fatal: git-write-tree: error building trees
+[2025-04-20 04:27:25.065295] (Utility.Process) process [12757] done ExitFailure 128
+git-annex: failed to read sha from git write-tree
+```
+
+This first showed up when I tried to do: `git annex sync myremote`
+Now this error keeps showing up but only in my computer's repo.
+
+Note: The object id shown doesn't seem to correspond to anything on my other drives.
+
+I'm worried it might be something in the latest version.
+
+On the external SSD from which I tried to sync it shows:
+
+```
+trusted repositories: 0                                                                                                                                                                                                                              
+semitrusted repositories: 12  
+untrusted repositories: 1
+local annex keys: 245972
+local annex size: 2.7 terabytes
+annexed files in working tree: 404264
+size of annexed files in working tree: 3.54 terabytes
+combined annex size of all repositories: 9.46 terabytes
+backend usage: 
+        SHA256E: 404264
+bloom filter size: 32 mebibytes (49.2% full)
+```
+
+Any idea what this could be?
+
+Is it safe to fix this by just cloning the repo again and then replacing the annex directory?
+I'm not sure how to deal with this since I've never had this error before.
+
+version information:
+
+```
+$ git annex version
+git-annex version: 10.20250416
+build flags: Pairing TorrentParser MagicMime Servant Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.24.4 bloomfilter-2.0.1.2 crypton-1.0.4 DAV-1.3.4 feed-1.3.2.1 ghc-9.8.4 http-client-0.7.19 persistent-sqlite-2.13.3.0 torrent-10000.1.3 uuid-1.3.16
+key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 BLAKE2B256E BLAKE2B256 BLAKE2B512E BLAKE2B512 BLAKE2B160E BLAKE2B160 BLAKE2B224E BLAKE2B224 BLAKE2B384E BLAKE2B384 BLAKE2BP512E BLAKE2BP512 BLAKE2S256E BLAKE2S256 BLAKE2S160E BLAKE2S160 BLAKE2S224E BLAKE2S224 BLAKE2SP256E BLAKE2SP256 BLAKE2SP224E BLAKE2SP224 SHA1E SHA1 MD5E MD5 WORM URL GITBUNDLE GITMANIFEST VURL X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg rclone hook external compute mask
+operating system: darwin aarch64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 0 1 2 3 4 5 6 7 8 9 10
+local repository version: 10
+```
+
+Thank you,
+Liam
+"""]]

diff --git a/doc/bugs/SQLite3_database_disk_image_malformed/comment_1_b31c4dc9de7ffd644b045e44b579d112._comment b/doc/bugs/SQLite3_database_disk_image_malformed/comment_1_b31c4dc9de7ffd644b045e44b579d112._comment
new file mode 100644
index 0000000000..2b9f4ab4e9
--- /dev/null
+++ b/doc/bugs/SQLite3_database_disk_image_malformed/comment_1_b31c4dc9de7ffd644b045e44b579d112._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="puck"
+ avatar="http://cdn.libravatar.org/avatar/06d3f4f0a82dd00a84f8f8fabc8e537d"
+ subject="Better error message"
+ date="2025-04-20T01:52:45Z"
+ content="""
+Hey,
+
+I hit this again today, running 10.20230126-3, so I upgraded to 10.20250115-1~bpo12+1. New error messages, excellent! Including: The SQL trying to be run, and the error from sqlite.
+
+This included \"disk I/O error\" from sqlite. Further investigation, and the volume was out of space 🤦. Don't know if that was the case when I first hit this or not.
+
+Cheers,
+Andrew
+"""]]

diff --git a/doc/news/version_10.20241031.mdwn b/doc/news/version_10.20241031.mdwn
deleted file mode 100644
index 6e7fde8e94..0000000000
--- a/doc/news/version_10.20241031.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-git-annex 10.20241031 released with [[!toggle text="these changes"]]
-[[!toggleable text="""  * Sped up proxied downloads from special remotes, by streaming.
-  * Added GETORDERED request to external special remote protocol.
-    When the external special remote responds with ORDERED, it can stream
-    through a proxy.
-  * p2phttp: Support serving unauthenticated users while requesting
-    authentication for operations that need it. Eg, --unauth-readonly
-    can be combined with --authenv.
-  * p2phttp: Allow unauthenticated users to lock content by default.
-  * p2phttp: Added --unauth-nolocking option to prevent unauthenticated
-    users from locking content.
-  * Allow enabling the servant build flag with older versions of stm,
-    allowing building with ghc 9.0.2.
-  * git-remote-annex: Fix bug that prevented using it with external special
-    remotes, leading to protocol error messages involving "GITMANIFEST".
-  * adjust: Allow any order of options when combining --hide-missing with
-    options like --unlock.
-  * Support P2P protocol version 4. This allows DATA-PRESENT to be sent
-    after PUT (and in the HTTP P2P protocol, v4/put has a data-present
-    parameter). When used with a proxy to a special remote like a S3
-    bucket, this allows a custom client to upload content to S3 itself,
-    and then use the P2P protocol to inform the proxy that the content has
-    been stored there, which will result in the same git-annex branch state
-    updates as sending DATA via the proxy.
-  * Fix hang when receiving a large file into a proxied special remote."""]]
\ No newline at end of file
diff --git a/doc/news/version_10.20250416.mdwn b/doc/news/version_10.20250416.mdwn
new file mode 100644
index 0000000000..6768a0b469
--- /dev/null
+++ b/doc/news/version_10.20250416.mdwn
@@ -0,0 +1,19 @@
+git-annex 10.20250416 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Added the mask special remote.
+  * updatecluster, updateproxy: When a remote that has no annex-uuid is
+    configured as annex-cluster-node, warn and avoid writing bad data to
+    the git-annex branch.
+  * Fix build without the assistant.
+  * fsck: Avoid complaining about required content of dead repositories.
+  * drop: Avoid redundant object directory thawing.
+  * httpalso: Windows url fix.
+  * Added remote.name.annex-web-options config, which is a per-remote
+    version of the annex.web-options config.
+  * migrate: Fix --remove-size to work when a file is not present.
+    Fixes reversion introduced in version 10.20231129.
+  * Support git remotes that use a IPV6 link-local address with a zone ID.
+  * Support git remotes that use an url with a user name that is URL
+    encoded, or in the case of an "scp-style" url, a user name that must be
+    encoded to be legal in an URL.
+  * Fix git-lfs special remote ssh endpoint discovery when the repository
+    path is URL encoded."""]]
\ No newline at end of file

diff --git a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
index 8276b76761..1be0ab5b01 100644
--- a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
+++ b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
@@ -18,9 +18,9 @@ backbone.
 
 Even better, there was an experiment for "[Distributed Git over Named Data
 Networking](https://github.com/JonnyKong/GitSync)" and
-[npChat](https://github.com/named-data-mobile/ndn-photo-app/issues/186)
-both exist. Could NDN be used as the backbone for a built-in method for
-connections to be made for `git-annex` and set the foundation—pave the
+[npChat](https://github.com/named-data-mobile/ndn-photo-app/issues/186),
+and now [Ownly](https://github.com/pulsejet/ownly/issues/49) exists. Could 
+`git-annex` provide a revision control system and set the foundation—pave the
 way—for the perfect file synchronization/sharing app?
 
 _¹ Although, it might be nice to use

diff --git a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN/comment_2_1737a356893176448fee30439b6d4fd1._comment b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN/comment_2_1737a356893176448fee30439b6d4fd1._comment
new file mode 100644
index 0000000000..42c5ea86c3
--- /dev/null
+++ b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN/comment_2_1737a356893176448fee30439b6d4fd1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="kxra@ae0f8ab3caa4ebebe6b1a121dd41b6751182360e"
+ nickname="kxra"
+ avatar="http://cdn.libravatar.org/avatar/e5995b14be072d754efe051ef9d4c930"
+ subject="comment 2"
+ date="2025-04-15T21:23:58Z"
+ content="""
+I see, I tend to cite as much as possible, and only reference proprietary software because sadly there is plenty that has no similar libre option. I have removed the resiliosync link as well because its name is unique enough to look up, but left the Abstract reference as you put it since it is a generic name that may be hard to find otherwise.
+
+Thanks for the link // deduplication—will use that ticket now
+"""]]

diff --git a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
index 2974b157da..8276b76761 100644
--- a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
+++ b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
@@ -1,10 +1,11 @@
-Average users could get so much value out of a simple and intuitive p2p
-file-syncing service that is as polished as ResilioSync
-(https://www.resilio.com/sync/), provides revision control on arbitrary
-files like Abstract (version control for designers)
-(https://www.goabstract.com/), but open source like LibreVault, SyncThing
-and SparkleShare. This would be priceless for science, design, all sorts of
-collaborative workspaces, and especially for backups and data redundancy. 
+Average users could get so much value out of a simple and intuitive p2p 
+file-syncing service that is as polished as ResilioSync (formerly BitTorrent 
+Sync), provides revision control on arbitrary files like Abstract (version 
+control for designers) (https://www.goabstract.com/), but open source like 
+LibreVault & SyncThing, plus backed by a distributed revision/version control 
+system (DRCS/DVCS)¹ like SparkleShare. This would be priceless for science, 
+design, all sorts of collaborative workspaces, and especially for backups and 
+data redundancy. 
 
 Currently, `git-annex` depends on Tor and [Magic
 Wormhole](https://github.com/magic-wormhole/magic-wormhole) to
@@ -22,5 +23,12 @@ both exist. Could NDN be used as the backbone for a built-in method for
 connections to be made for `git-annex` and set the foundation—pave the
 way—for the perfect file synchronization/sharing app?
 
+_¹ Although, it might be nice to use
+[Pijul](https://pijul.org/manual/why_pijul.html), which has [efficient
+binary diffs](https://pijul.org/posts/2021-06-28-two-changes/) and 
+hopefully someday also [word-by-word d
+iffs](https://discourse.pijul.org/t/fast-characterwise-and-binary-patches/32/9) 
+(for example, to be the revision control system for a wiki)_
+
 > treating this as a duplicate of [[todo/generic_p2p_socket_transport]];
 > [[done]] --[[Joey]]

diff --git a/doc/devblog/youtube-dl/comment_2_09f6e67b152806b8ade952a9c4858375._comment b/doc/devblog/youtube-dl/comment_2_09f6e67b152806b8ade952a9c4858375._comment
new file mode 100644
index 0000000000..f315ba2564
--- /dev/null
+++ b/doc/devblog/youtube-dl/comment_2_09f6e67b152806b8ade952a9c4858375._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="alex@5879ea369269daf3c1bd734246d83dd55d12f2da"
+ nickname="alex"
+ avatar="http://cdn.libravatar.org/avatar/fffc45a4d972ca89ae78df01d2c752a3"
+ subject="yt-dlp did not put any media in its work directory"
+ date="2025-04-15T14:15:37Z"
+ content="""
+Here's the translation:
+
+I've encountered an issue. I am using yt-dlp with the following settings:
+annex.youtube-dl-options \"--proxy socks5://127.0.0.1:1080 --config-locations ~/.config/yt-dlp/config\"
+
+But when I try to download a video playlist using git-annex addurl, I always get the following error:
+yt-dlp did not put any media in its work directory, perhaps it's been configured to store files somewhere else?
+
+What could be the problem?
+
+Thanks in advance.
+"""]]

diff --git a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
index 6401148e0f..2974b157da 100644
--- a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
+++ b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
@@ -1,5 +1,26 @@
-Average users could get so much value out of a simple and intuitive p2p file-syncing service that is as polished as [ResilioSync](https://www.resilio.com/sync/), provides revision control on arbitrary files like [Abstract (version control for designers)](https://www.goabstract.com/), but open source like LibreVault, SyncThing and SparkleShare. This would be priceless for science, design, all sorts of collaborative workspaces, and especially for backups and data redundancy. 
+Average users could get so much value out of a simple and intuitive p2p
+file-syncing service that is as polished as ResilioSync
+(https://www.resilio.com/sync/), provides revision control on arbitrary
+files like Abstract (version control for designers)
+(https://www.goabstract.com/), but open source like LibreVault, SyncThing
+and SparkleShare. This would be priceless for science, design, all sorts of
+collaborative workspaces, and especially for backups and data redundancy. 
 
-Currently, `git-annex` depends on Tor and [Magic Wormhole](https://github.com/magic-wormhole/magic-wormhole) to share/collaborate/sync with others. There is [Hypercore](https://docs.pears.com/building-blocks/hypercore) by [Holepunch](https://holepunch.to/), but [Named Data Networking (NDN)](https://named-data.net/project/archoverview/) ([video](https://youtu.be/qbAB0iN1-zQ)) offers a more robust internet backbone. 
+Currently, `git-annex` depends on Tor and [Magic
+Wormhole](https://github.com/magic-wormhole/magic-wormhole) to
+share/collaborate/sync with others. There is
+[Hypercore](https://docs.pears.com/building-blocks/hypercore) by
+[Holepunch](https://holepunch.to/), but [Named Data Networking
+(NDN)](https://named-data.net/project/archoverview/)
+([video](https://youtu.be/qbAB0iN1-zQ)) offers a more robust internet
+backbone. 
 
-Even better, there was an experiment for "[Distributed Git over Named Data Networking](https://github.com/JonnyKong/GitSync)" and [npChat](https://github.com/named-data-mobile/ndn-photo-app/issues/186) both exist. Could NDN be used as the backbone for a built-in method for connections to be made for `git-annex` and set the foundation—pave the way—for the perfect file synchronization/sharing app?
+Even better, there was an experiment for "[Distributed Git over Named Data
+Networking](https://github.com/JonnyKong/GitSync)" and
+[npChat](https://github.com/named-data-mobile/ndn-photo-app/issues/186)
+both exist. Could NDN be used as the backbone for a built-in method for
+connections to be made for `git-annex` and set the foundation—pave the
+way—for the perfect file synchronization/sharing app?
+
+> treating this as a duplicate of [[todo/generic_p2p_socket_transport]];
+> [[done]] --[[Joey]]
diff --git a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN/comment_1_f511d430a948a9048eb8e8cede047bd4._comment b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN/comment_1_f511d430a948a9048eb8e8cede047bd4._comment
new file mode 100644
index 0000000000..8a053cada9
--- /dev/null
+++ b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN/comment_1_f511d430a948a9048eb8e8cede047bd4._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2025-04-15T13:31:34Z"
+ content="""
+Honestly, your message somewhat triggered my internal spam filters. In
+particular, its linking to multiple proprietary services adjacent to
+glowing language about them. Also the very
+similar language and linking in your post at
+<https://github.com/named-data-mobile/ndn-photo-app/issues/186>.
+
+For this reason, I have removed some hyperlinks from your post.
+While I think, on review, that you are acting in good faith,
+I also think it's important you understand a post like this can
+cause that kind of reaction these days. And removing the links
+will thus help no matter what.
+
+---
+
+There is actually an open todo at [[todo/generic_p2p_socket_transport]]
+which I think could probably be used to implement what you are envisioning.
+
+So my suggestion is you review that proposed design and see if it would
+support the use cases you are envisioning. And if not, what changes would
+need to be made.
+"""]]

diff --git a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
index 4dfde78906..6401148e0f 100644
--- a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
+++ b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
@@ -2,4 +2,4 @@ Average users could get so much value out of a simple and intuitive p2p file-syn
 
 Currently, `git-annex` depends on Tor and [Magic Wormhole](https://github.com/magic-wormhole/magic-wormhole) to share/collaborate/sync with others. There is [Hypercore](https://docs.pears.com/building-blocks/hypercore) by [Holepunch](https://holepunch.to/), but [Named Data Networking (NDN)](https://named-data.net/project/archoverview/) ([video](https://youtu.be/qbAB0iN1-zQ)) offers a more robust internet backbone. 
 
-Even better, there was an experiment for "[Distributed Git over Named Data Networking](https://github.com/JonnyKong/GitSync/issues/2)". Could NDN be used as the backbone for a built-in method for connections to be made for `git-annex` and set the foundation—pave the way—for the perfect file synchronization/sharing app?
+Even better, there was an experiment for "[Distributed Git over Named Data Networking](https://github.com/JonnyKong/GitSync)" and [npChat](https://github.com/named-data-mobile/ndn-photo-app/issues/186) both exist. Could NDN be used as the backbone for a built-in method for connections to be made for `git-annex` and set the foundation—pave the way—for the perfect file synchronization/sharing app?

diff --git a/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
new file mode 100644
index 0000000000..4dfde78906
--- /dev/null
+++ b/doc/todo/Abstract__44__LibreVault__44__ResilioSync_alternative_on_NDN.mdwn
@@ -0,0 +1,5 @@
+Average users could get so much value out of a simple and intuitive p2p file-syncing service that is as polished as [ResilioSync](https://www.resilio.com/sync/), provides revision control on arbitrary files like [Abstract (version control for designers)](https://www.goabstract.com/), but open source like LibreVault, SyncThing and SparkleShare. This would be priceless for science, design, all sorts of collaborative workspaces, and especially for backups and data redundancy. 
+
+Currently, `git-annex` depends on Tor and [Magic Wormhole](https://github.com/magic-wormhole/magic-wormhole) to share/collaborate/sync with others. There is [Hypercore](https://docs.pears.com/building-blocks/hypercore) by [Holepunch](https://holepunch.to/), but [Named Data Networking (NDN)](https://named-data.net/project/archoverview/) ([video](https://youtu.be/qbAB0iN1-zQ)) offers a more robust internet backbone. 
+
+Even better, there was an experiment for "[Distributed Git over Named Data Networking](https://github.com/JonnyKong/GitSync/issues/2)". Could NDN be used as the backbone for a built-in method for connections to be made for `git-annex` and set the foundation—pave the way—for the perfect file synchronization/sharing app?

diff --git a/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_5_8423d36a81a91aacce9e1906baee5626._comment b/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_6_8423d36a81a91aacce9e1906baee5626._comment
similarity index 92%
rename from doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_5_8423d36a81a91aacce9e1906baee5626._comment
rename to doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_6_8423d36a81a91aacce9e1906baee5626._comment
index 8472398e18..0ef8fc920d 100644
--- a/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_5_8423d36a81a91aacce9e1906baee5626._comment
+++ b/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_6_8423d36a81a91aacce9e1906baee5626._comment
@@ -1,6 +1,6 @@
 [[!comment format=mdwn
  username="joey"
- subject="""comment 5"""
+ subject="""comment 6"""
  date="2025-04-11T17:20:08Z"
  content="""
 Implemented this as the mask special remote. 
diff --git a/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_7_57aac89ca247fb312fd4874d2f51a198._comment b/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_7_57aac89ca247fb312fd4874d2f51a198._comment
new file mode 100644
index 0000000000..6790e393a7
--- /dev/null
+++ b/doc/todo/encrypt_just_the_annex_on_git+annex_hosting_site/comment_7_57aac89ca247fb312fd4874d2f51a198._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2025-04-11T17:23:59Z"
+ content="""
+> Could such a special remote use the same \"transport\" as the underlying remote (thinking of p2p http in particular), which would mean the same authentication & the same set of permissions server side?
+
+Yes, the underlying remote is used as-is, whatever it is.
+"""]]