diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_5_8f71510a7547db8d0c63e4a4e3ddbd65._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_5_8f71510a7547db8d0c63e4a4e3ddbd65._comment
new file mode 100644
index 0000000000..d81bf9b141
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_5_8f71510a7547db8d0c63e4a4e3ddbd65._comment
@@ -0,0 +1,47 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="comment 5"
+ date="2022-10-01T08:23:43Z"
+ content="""
+Yes, thank you, Joey! The annoying (but sometimes necessary) reminder is gone now in regular get/drop
+circumstances:
+
+[[!format sh \"\"\"
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg ok
+(recording state in git...)
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
+
+    Directory: K:\Reflect-varmistukset\.git\annex
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           1.10.2022    11:08              0 restage.log
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> time git annex get 79698DAC29A079D3-06-06.mrimg
+get 79698DAC29A079D3-06-06.mrimg (from origin...)
+ok
+(recording state in git...)
+00:01:50.7710391
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
+
+    Directory: K:\Reflect-varmistukset\.git\annex
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           1.10.2022    11:11              0 restage.log
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex version --raw
+10.20220928-g49ee07f93
+\"\"\"]]
+
+:)
+
+"""]]

diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_4_42ef3d3d157a97a202718f3b768916f8._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_4_42ef3d3d157a97a202718f3b768916f8._comment
new file mode 100644
index 0000000000..ac5bc2b181
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_4_42ef3d3d157a97a202718f3b768916f8._comment
@@ -0,0 +1,45 @@
+[[!comment format=mdwn
+ username="jkniiv"
+ avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
+ subject="restage.log was empty indeed"
+ date="2022-10-01T05:14:17Z"
+ content="""
+Just for completeness sake:
+
+[[!format sh \"\"\"
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git-annex version --raw
+10.20220927-g26dea5641
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg ok
+(recording state in git...)
+
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
+
+    Directory: K:\Reflect-varmistukset\.git\annex
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           1.10.2022     7:47              0 restage.log
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> time git annex get 79698DAC29A079D3-06-06.mrimg
+get 79698DAC29A079D3-06-06.mrimg (from origin...)
+ok
+(recording state in git...)
+
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+00:01:53.0001475
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
+
+    Directory: K:\Reflect-varmistukset\.git\annex
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           1.10.2022     8:02              0 restage.log
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+\"\"\"]]
+
+"""]]

diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_2_8ecb958a1a2c8cd9fd37798c0d4eb0cf._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_2_8ecb958a1a2c8cd9fd37798c0d4eb0cf._comment
new file mode 100644
index 0000000000..c371e292bc
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_2_8ecb958a1a2c8cd9fd37798c0d4eb0cf._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-30T17:43:13Z"
+ content="""
+Found the bug: "fd:16: hFlush: illegal operation (handle is closed)"
+This exception gets caught after it's actually finished restaging
+everything, so it displays the warning unncessarily.
+
+Pretty sure the problem on Windows will have the same cause.
+"""]]
diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_3_aed127be0616464fda064f00de954fc2._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_3_aed127be0616464fda064f00de954fc2._comment
new file mode 100644
index 0000000000..30745fff7d
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_3_aed127be0616464fda064f00de954fc2._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-30T17:55:20Z"
+ content="""
+I've fixed this, and I'm planning to make a minor release on Monday for it.
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index e077b498ad..ca6fc34343 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -2,6 +2,8 @@ git-annex (10.20220928) UNRELEASED; urgency=medium
 
   * Avoid displaying warning about git-annex restage needing to be run
     in situations where it does not.
+  * Fix the annex.adviceNoSshCaching config, which has never worked.
+    Thanks, Reiko Asakura
 
  -- Joey Hess <id@joeyh.name>  Fri, 30 Sep 2022 13:54:23 -0400
 
diff --git a/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn b/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn
index c5b120713f..082a73997b 100644
--- a/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn
+++ b/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn
@@ -26,3 +26,5 @@ index 44629d412..4b892bd5f 100644
 2.30.2
 
 ```
+
+> Thanks for the fix! [[done]] --[[Joey]]

diff --git a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
index eb115d29b4..683361bb02 100644
--- a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
+++ b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
@@ -9,10 +9,10 @@ The following steps are tested on Windows 10 21h1 with Ubuntu 20 and are designe
 
 * Enable Developer mode in Windows settings so that symlinks can be created without elevated privileges.
 * Mount the NTFS drive with metadata option. [`/etc/wsl.conf`](https://docs.microsoft.com/en-us/windows/wsl/wsl-config) can be used or a line such as `C: /mnt/c drvfs metadata` can be added in `/etc/fstab`.
-* Initialize the repo.
-    * If the repository is created by cloning, create local git-annex branch from the remote branch and remove the origin remote before `git annex init`.
-    * Set `git config annex.crippledfilesystem true` immediately after `git annex init`.
-    * Add the origin remote back if it was previously removed.
+* Follow these steps in order when creating a new repository.
+    * `git config annex.sshcaching false`
+    * `git annex init`
+    * git-annex should not detect the filesystem as crippled but now set `git config annex.crippledfilesystem true`
 * Safety of locked files will require these settings and scripts and the patch below.
     * `git config annex.freezecontent-command 'wsl-freezecontent %path'`
     * `git config annex.thawcontent-command 'wsl-thawcontent %path'`
@@ -105,7 +105,7 @@ index 39853c894..2d66c1461 100644
 
 ** Usage tips **
 
-* Symlinks are invalid in Windows if created before the target file exists, such as after `git annex add` or `git annex get`. This can be fixed by recreating them with any method, such as delete them and `git checkout`.
+* WSL1 will not create symlinks that work in Windows if created before the target file exists, such as after `git annex add` or `git annex get`. This can be fixed by recreating them with any method, such as delete them and `git checkout`.
 
 <details>
 <summary>Sample script to recreate all symlinks under the current directory</summary>

diff --git a/CHANGELOG b/CHANGELOG
index e805419551..e077b498ad 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,10 @@
+git-annex (10.20220928) UNRELEASED; urgency=medium
+
+  * Avoid displaying warning about git-annex restage needing to be run
+    in situations where it does not.
+
+ -- Joey Hess <id@joeyh.name>  Fri, 30 Sep 2022 13:54:23 -0400
+
 git-annex (10.20220927) upstream; urgency=medium
 
   * Fix a bug in the last release that caused v8 repositories to upgrade
diff --git a/Git/UpdateIndex.hs b/Git/UpdateIndex.hs
index ee34afe983..0ac21617fb 100644
--- a/Git/UpdateIndex.hs
+++ b/Git/UpdateIndex.hs
@@ -160,7 +160,6 @@ refreshIndex repo feeder = bracket
 
 	go (Just h, _, _, pid) = do
 		let closer = do
-			hFlush h
 			hClose h
 			forceSuccessProcess p pid
 		feeder $ \case
diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn
index bc1bbf8a50..4b4c10d4d4 100644
--- a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn
@@ -178,3 +178,5 @@ Git Annex is great. I use it several times a week with my multigigabyte backups,
 Big thanks, Joey!
 
 [[!meta author=jkniiv]]
+
+> [[fixed|done]] --[[Joey]]

diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_6_a959fa6cb5b4cda423b7e75aeec2eb1c._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_6_a959fa6cb5b4cda423b7e75aeec2eb1c._comment
new file mode 100644
index 0000000000..e0e05d74be
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_6_a959fa6cb5b4cda423b7e75aeec2eb1c._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-30T17:34:34Z"
+ content="""
+Thanks for confirming my feeling that something about the bug as reported
+was not quite right.
+
+It it was keysdb.cache or keysdb.lck, then it might be a locking problem in
+git-annex.
+
+But it seems more likely it was `keysdb/*`.. And that is a sqlite database.
+And if sqlite has problems with its internal locking that don't work on
+your filesystem, it would be hard to fix that in git-annex. Not using
+sqlite or switching the database from WAL mode to non-WAL mode are about
+all git-annex could do and both would be major undertakings.
+
+A recently added feature to git-annex is the annex.dbdir git config.
+That can be set to a directory on another filesystem, and git-annex will
+store all its sqlite databases in that directory. I think this option is
+your best chance of avoiding the problem.
+"""]]

diff --git a/doc/design/external_special_remote_protocol.mdwn b/doc/design/external_special_remote_protocol.mdwn
index 365ee6cf4d..3d2f0588ae 100644
--- a/doc/design/external_special_remote_protocol.mdwn
+++ b/doc/design/external_special_remote_protocol.mdwn
@@ -291,14 +291,14 @@ handling a request.
   tracking the size of the file as it grows.)  
   (git-annex does not send a reply to this message.)
 * `DIRHASH Key`  
-  Gets a two level hash associated with a Key. Something like "aB/Cd".
+  Gets a two level hash associated with a Key. Something like "aB/Cd/".
   This is always the same for any given Key, so can be used for eg,
   creating hash directory structures to store Keys in. This is the same
   directory hash that git-annex uses inside `.git/annex/objects/`  
   (git-annex replies with VALUE followed by the value.)
 * `DIRHASH-LOWER Key`  
   Gets a two level hash associated with a Key, using only lower-case.
-  Something like "abc/def".
+  Something like "abc/def/".
   This is always the same for any given Key, so can be used for eg,
   creating hash directory structures to store Keys in. This is the same
   directory hash that is used by eg, the directory special remote.  
diff --git a/doc/design/external_special_remote_protocol/comment_51_c0eaa8639ad2b21ac917d9033d77a327._comment b/doc/design/external_special_remote_protocol/comment_51_c0eaa8639ad2b21ac917d9033d77a327._comment
new file mode 100644
index 0000000000..449ae3a6e5
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_51_c0eaa8639ad2b21ac917d9033d77a327._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: DIRHASH ending in slash?"""
+ date="2022-09-30T17:31:25Z"
+ content="""
+Hmm, so it does. This would not have been my choice for ideal behavior, but
+I don't want to break things that depend on it now. 
+So I've updated the documentation.
+"""]]

diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_1_e738eb3d45bb7c4baa0a5c88cdf7a40a._comment b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_1_e738eb3d45bb7c4baa0a5c88cdf7a40a._comment
new file mode 100644
index 0000000000..a5594e67c0
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__/comment_1_e738eb3d45bb7c4baa0a5c88cdf7a40a._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1t"""
+ date="2022-09-30T17:24:27Z"
+ content="""
+Not sure this is quite the same situation, but on linux, I am seeing
+`git-annex unlock` of a locked file display the warning.
+
+Also, .git/annex/restage.log is left empty after the command completes.
+Which seems to indicate it managed to restage the file after all. Is that
+file empty for you on windows after it displays the warning and before
+running other commands?
+"""]]

diff --git a/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn b/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn
new file mode 100644
index 0000000000..c5b120713f
--- /dev/null
+++ b/doc/todo/__91__PATCH__93___Fix_annex.adviceNoSshCaching_no_effect.mdwn
@@ -0,0 +1,28 @@
+```
+From 1a67bc14aa74262a304e7b6bd6372b0eca40486e Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Fri, 30 Sep 2022 10:56:17 -0400
+Subject: [PATCH] Fix annex.adviceNoSshCaching having no effect
+
+git will always return option names in lowercase
+---
+ Types/GitConfig.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Types/GitConfig.hs b/Types/GitConfig.hs
+index 44629d412..4b892bd5f 100644
+--- a/Types/GitConfig.hs
++++ b/Types/GitConfig.hs
+@@ -265,7 +265,7 @@ extractGitConfig configsource r = GitConfig
+ 			| otherwise = Nothing
+ 		  in mapMaybe get (M.toList (Git.config r))
+ 		]
+-	, annexAdviceNoSshCaching = getbool (annexConfig "adviceNoSshCaching") True
++	, annexAdviceNoSshCaching = getbool (annexConfig "advicenosshcaching") True
+ 	}
+   where
+ 	getbool k d = fromMaybe d $ getmaybebool k
+-- 
+2.30.2
+
+```

diff --git a/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn
new file mode 100644
index 0000000000..bc1bbf8a50
--- /dev/null
+++ b/doc/bugs/windows__58___needlessly_reminded_to_run___96__restage__96__.mdwn
@@ -0,0 +1,180 @@
+### Please describe the problem.
+
+After release 10.20220927 any get or drop command that changes availability of content causes git-annex
+to issue the following notice:
+
+```
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+``` 
+
+Yet git status is clean and no `git-annex restage` is needed.
+
+### What steps will reproduce the problem?
+
+Use a crippled filesystem on Windows with adjusted unlocked branches and try to get content from a remote or drop content locally.
+
+### What version of git-annex are you using? On what operating system?
+
+[[!format sh """
+git-annex version: 10.20220927-g26dea5641
+build flags: Assistant Webapp Pairing TorrentParser Benchmark Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.29 DAV-1.3.4 feed-1.3.2.0 ghc-8.10.7 http-client-0.7.9 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.1.2
+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 X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg hook external
+operating system: mingw32 x86_64
+supported repository versions: 8 9 10
+upgrade supported from repository versions: 2 3 4 5 6 7 8 9 10
+"""]]
+
+The above is for all practical purposes the released version 10.20220927, just a few commits before the release with no code changes.
+
+Windows 10 version 21H2 (build 19044.2006), 64 bit.
+
+### Please provide any additional information below.
+
+[[!format sh """
+C:\Users\jkniiv> k:
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B\arkistoidut [adjusted/master(unlocked)]> cd ..
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> duf .
+╭─────────────────────────────────────────────────────────────────────╮
+│ 1 local device                                                      │
+├────────────┬──────┬──────┬───────┬────────┬──────┬──────────────────┤
+│ MOUNTED ON │ SIZE │ USED │ AVAIL │  USE%  │ TYPE │ FILESYSTEM       │
+├────────────┼──────┼──────┼───────┼────────┼──────┼──────────────────┤
+│ K:\        │ 3.6T │ 3.6T │ 34.9G │  99.1% │ NTFS │ Jibun.Tila2109kc │
+╰────────────┴──────┴──────┴───────┴────────┴──────┴──────────────────╯
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex-sync --content
+merge synced/master (Merging into master...)
+Updating 6d4e731..05224ad
+Fast-forward
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 120000 Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg
+(Merging into adjusted branch...)
+Updating 51cb822..f175b90
+Fast-forward
+ Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg
+ok
+pull origin
+From G:\Reflect-varmistukset
+   f984af1..013ea2d  git-annex     -> origin/git-annex
+   6d4e731..05224ad  master        -> origin/master
+   6d4e731..05224ad  synced/master -> origin/synced/master
+ok
+get Jarkon ThinkPad T450s (Win10 v21H1) . B/79698DAC29A079D3-06-06.mrimg (from origin...)
+ok
+pull origin
+ok
+(recording state in git...)
+push origin
+Enumerating objects: 9, done.
+Counting objects: 100% (9/9), done.
+Delta compression using up to 4 threads
+Compressing objects: 100% (5/5), done.
+Writing objects: 100% (5/5), 476 bytes | 238.00 KiB/s, done.
+Total 5 (delta 2), reused 0 (delta 0), pack-reused 0
+To G:\Reflect-varmistukset
+   f984af1..3ebe493  git-annex -> synced/git-annex
+ok
+(recording state in git...)
+
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex version --raw
+10.20220927-g26dea5641
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg (unsafe)
+  Could only verify the existence of 1 out of 2 necessary copies
+
+  Rather than dropping this file, try using: git annex move
+
+  (Use --force to override this check, or adjust numcopies.)
+failed
+drop: 1 failed
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg ok
+(recording state in git...)
+
+  git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> echo "Installing version 10.20220823-g34e313f78 in the background"
+Installing version 10.20220823-g34e313f78 in the background
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex version --raw
+10.20220823-g34e313f78
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls 79698DAC29A079D3-06-06.mrimg
+
+    Directory: K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           30.9.2022    14:53             87 79698DAC29A079D3-06-06.mrimg
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex get 79698DAC29A079D3-06-06.mrimg
+get 79698DAC29A079D3-06-06.mrimg (from origin...)
+ok
+(recording state in git...)
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
+drop 79698DAC29A079D3-06-06.mrimg ok
+(recording state in git...)
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
+On branch adjusted/master(unlocked)
+nothing to commit, working tree clean
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls 79698DAC29A079D3-06-06.mrimg
+
+    Directory: K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B
+
+Mode                 LastWriteTime         Length Name
+----                 -------------         ------ ----
+-a---           30.9.2022    15:01             87 79698DAC29A079D3-06-06.mrimg
+
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> head 79698DAC29A079D3-06-06.mrimg
+/annex/objects/BLAKE2B160E-s8305341589--ab8ca27391c2f68c1c4d677942deaf5022498752.mrimg
+K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> cat ..\.git\config
+[core]
+        repositoryformatversion = 0
+        filemode = false
+        bare = false
+        logallrefupdates = true
+        symlinks = false
+        ignorecase = true
+[interactive]
+        diffFilter = delta --color-only
+[remote "origin"]
+        url = G:\\Reflect-varmistukset
+        fetch = +refs/heads/*:refs/remotes/origin/*
+        fetch = ^refs/heads/adjusted/*
+        annex-uuid = redacted1-1789-4471-96a0-redactedabcd
+[annex]
+        thin = true
+        backend = MD5E
+        maxextensionlength = 8
+        uuid = redacted2-45c8-4a86-b348-redactedabcd
+        sshcaching = false
+        crippledfilesystem = true
+        version = 10
+        diskreserve = 1000M
+[filter "annex"]
+        smudge = git-annex smudge -- %f
+        clean = git-annex smudge --clean -- %f
+[merge]
+        renames = true
+        directoryRenames = false
+
+# End of transcript or log.
+"""]]
+
+Btw. the git `annex-sync` alias above is defined to be `annex sync --no-commit`.
+
+### 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)
+
+Git Annex is great. I use it several times a week with my multigigabyte backups, where it gives structure to my image-based backup routines, so you could say I'm a believer. :)
+
+Big thanks, Joey!
+
+[[!meta author=jkniiv]]

diff --git a/doc/bugs/android_sync_messes_tree/comment_1_a90afb9011c760843836728d03353619._comment b/doc/bugs/android_sync_messes_tree/comment_1_a90afb9011c760843836728d03353619._comment
new file mode 100644
index 0000000000..95f83f70d7
--- /dev/null
+++ b/doc/bugs/android_sync_messes_tree/comment_1_a90afb9011c760843836728d03353619._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="jules@a6ba859eba6f59bd980f294741b1ad9b7624552a"
+ nickname="jules"
+ avatar="http://cdn.libravatar.org/avatar/a751e2ef9129dfaf6c68a0d762e5db60"
+ subject="mess up commited to my branch"
+ date="2022-09-29T09:26:05Z"
+ content="""
+I noticed that even when the syncing finishes. Worse than that, the 'android/master' branch is merged into 'master'.
+The removed files are brought back during the merge, but the moved files are committed.
+
+I definitely don't want git annex to touch my master branch. I have 'autocommit = false', 'synconlyannex = true' and 'alwayscommit = false'. I take care of merging and pushing the 'git-annex' branch myself.
+
+Perhaps I'm not using git-annex right ?
+"""]]

diff --git a/doc/bugs/android_sync_messes_tree.mdwn b/doc/bugs/android_sync_messes_tree.mdwn
new file mode 100644
index 0000000000..204df363f2
--- /dev/null
+++ b/doc/bugs/android_sync_messes_tree.mdwn
@@ -0,0 +1,39 @@
+### Please describe the problem.
+
+Hi,
+
+I'm trying to sync some files to my Android phone using the adb special remote.
+
+Of course, I have a complicated 'wanted' expression: I want new files matching a query be exported automatically on 'sync' and files added on the phone be imported automatically. I also want the files I manually export to the phone to stay where they are.
+
+I'm still debugging my 'wanted' expression,
+I run 'git annex sync --content',
+notice it isn't syncing the right files,
+ctrl+C.
+
+My worktree is left in a weird state: All the files are moved or removed.
+It seems git-annex made the worktree into the desired shape for syncing. However, it did that with my main worktree, which is annoying.
+
+To recover from that, 'git reset --hard' works but I also need to do 'git add' then 'git annex fix'.
+
+Is here a reason to use the main worktree instead of a temporary directory to do that ?
+
+Also, it makes a branch 'android/master' which seems weird. First, it doesn't look like 'master' at all, a cryptic name would be better.
+This branch isn't supposed to be pushed anywhere and generates tons of conflicts every time, I don't think it should do a branch at all.
+Why not rebuild the desired tree into a temporary directory without storing it in git in any way ?
+
+### What steps will reproduce the problem?
+
+Have an 'adb' remote with 'annex-tracking-branch' set to a subdirectory, 'master:subdirectory'.
+Kill the process while it is syncing files.
+
+### What version of git-annex are you using? On what operating system?
+
+git-annex version: 10.20220504
+Android Debug Bridge version 1.0.41 (31.0.3p1-android-tools)
+
+### 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)
+
+I've been using git-annex for a year and it has been awesome for me ! I'm trusting it more and more and that's why I'm trying new things with it.
+
+Thanks a lot for the awesome work !

diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_5_6439cb8500ad225fc4ef43a18582b18a._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_5_6439cb8500ad225fc4ef43a18582b18a._comment
new file mode 100644
index 0000000000..1ffab986a0
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_5_6439cb8500ad225fc4ef43a18582b18a._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="comment 5"
+ date="2022-09-28T12:55:49Z"
+ content="""
+So I think I have this issue completely wrong, apologies.
+
+
+The problem recurred again today, on a v8 repo, and with yesterday's release of git-annex. There is definitely a problem with locking, but it can't be due to the changes in version 10.
+
+To debug further, I removed only some files at a time from the .git/annex directory. The offending files were the keysdb (I did `rm -rf keysdb*`, so I'm not sure which of the specific files were the offenders).
+
+I'll keep you posted as I debug it further, but I thought I should let you know immediately that my original diagnosis was wrong.
+"""]]

diff --git a/doc/design/external_special_remote_protocol/comment_50_fdd9804134e6fe5e6527f35fc782cb80._comment b/doc/design/external_special_remote_protocol/comment_50_fdd9804134e6fe5e6527f35fc782cb80._comment
new file mode 100644
index 0000000000..023d8435dc
--- /dev/null
+++ b/doc/design/external_special_remote_protocol/comment_50_fdd9804134e6fe5e6527f35fc782cb80._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jeroen"
+ avatar="http://cdn.libravatar.org/avatar/72187d05d3414dc8e5766c5575a2d255"
+ subject="DIRHASH ending in slash?"
+ date="2022-09-28T11:58:56Z"
+ content="""
+DIRHASH-LOWER (and I assume the other DIRHASH commands as well) seem to respond with a path ending with a slash. So `VALUE abc/def/` instead of the `VALUE abc/def` example mentioned. `git-annex-remote-rclone` actually assumes the response ends with a slash. Is this indeed what git-annex guarantees? If so, it should probably be documented in this specification.
+"""]]

diff --git a/doc/forum/Ensure_all_versions_are_on_remotes/comment_5_2202121e5311b56b1d73f9bb1503c5e3._comment b/doc/forum/Ensure_all_versions_are_on_remotes/comment_5_2202121e5311b56b1d73f9bb1503c5e3._comment
new file mode 100644
index 0000000000..6511f657a8
--- /dev/null
+++ b/doc/forum/Ensure_all_versions_are_on_remotes/comment_5_2202121e5311b56b1d73f9bb1503c5e3._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 5"
+ date="2022-09-28T08:40:11Z"
+ content="""
+Thanks for looking into this, and explaining. Your final configuration makes sense to me... I can't say I fully understand why, but I need `-a` otherwise the local repo will get all versions, leaving me with a bunch of unused keys. So my command is `git annex sync -a -A wasabi-east wasabi-west`. I took the other machine out of the sync because sometimes it's offline and I don't want to wait around for an SSH timeout.
+
+I have tested that if I force drop a key from `wasabi-east`, that sync command will get the key from `wasabi-west`, and then copy it to `wasabi-east`. It doesn't automatically drop it locally, I have to do `git annex drop --unused` - but that's not a big deal.
+
+I would just like to be confident that the wasabi remotes are a lockbox for any keys added to my annex. So... I think it works? :)  I'll keep using it and report back if I run into any weirdness.
+"""]]

diff --git a/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_5_d0d7674589574ae92e2595d23d000f61._comment b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_5_d0d7674589574ae92e2595d23d000f61._comment
new file mode 100644
index 0000000000..20dafd50a7
--- /dev/null
+++ b/doc/forum/How_to_forget_keys_that_get_can__39__t_find__63__/comment_5_d0d7674589574ae92e2595d23d000f61._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="pat"
+ avatar="http://cdn.libravatar.org/avatar/6b552550673a6a6df3b33364076f8ea8"
+ subject="comment 5"
+ date="2022-09-28T07:43:28Z"
+ content="""
+It's working great here, thanks!!
+"""]]

diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_d54eb28d30d91088de019b761a340fd3._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_4_d54eb28d30d91088de019b761a340fd3._comment
similarity index 60%
rename from doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_d54eb28d30d91088de019b761a340fd3._comment
rename to doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_4_d54eb28d30d91088de019b761a340fd3._comment
index 1db69d2241..3d0ae56df3 100644
--- a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_d54eb28d30d91088de019b761a340fd3._comment
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_4_d54eb28d30d91088de019b761a340fd3._comment
@@ -1,13 +1,18 @@
 [[!comment format=mdwn
  username="joey"
- subject="""comment 3"""
+ subject="""comment 4"""
  date="2022-09-27T18:54:32Z"
  content="""
 FWIW, I don't see this problem in a v10 repo on ext4. I set annex.pidlock in
 case it being set somehow causes a locking problem.
 
-Try running a command like this, in a repo where it hangs, to debug at what
+Try running this, in a repo where it hangs, to debug at what
 point in the git-annex filter-process it is hanging.
 
 	GIT_TRACE_PACKET=1 GIT_TRACE=1 git status
+
+Then try disabling filter-process and confirm if it hangs or not:
+
+	git config --unset filter.annex.process
+	git status
 """]]

diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_d54eb28d30d91088de019b761a340fd3._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_d54eb28d30d91088de019b761a340fd3._comment
new file mode 100644
index 0000000000..1db69d2241
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_d54eb28d30d91088de019b761a340fd3._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-27T18:54:32Z"
+ content="""
+FWIW, I don't see this problem in a v10 repo on ext4. I set annex.pidlock in
+case it being set somehow causes a locking problem.
+
+Try running a command like this, in a repo where it hangs, to debug at what
+point in the git-annex filter-process it is hanging.
+
+	GIT_TRACE_PACKET=1 GIT_TRACE=1 git status
+"""]]

diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_c863d6940528fcc543815da44e7997d5._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_c863d6940528fcc543815da44e7997d5._comment
new file mode 100644
index 0000000000..cc71a56e3e
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_3_c863d6940528fcc543815da44e7997d5._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="comment 3"
+ date="2022-09-27T18:40:40Z"
+ content="""
+Thanks for that Joey, I'll upgrade to today's release and let you know if the problem persists. Regarding filter-process, I think I was unclear: it stalls *during* filter-process, not *because of* filter-process. I gather filter-process gets stuck waiting for a lock. 
+"""]]

diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_2_e262ec0e438557b8d70a6adc50545ac1._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_2_e262ec0e438557b8d70a6adc50545ac1._comment
new file mode 100644
index 0000000000..b200189dbc
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_2_e262ec0e438557b8d70a6adc50545ac1._comment
@@ -0,0 +1,19 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-27T18:21:12Z"
+ content="""
+If filter-process is the problem, it does not make sense that repo v9
+v9 would not have the problem, because v9 enables filter-process.
+If v9 is ok and only v10 has the problem then it must have something to
+do with the locking changes in v10.
+
+Also, you can upgrade to v9/v10 and still disable git-annex filter-process,
+by running this after the upgrade:
+
+	git config --unset filter.annex.process
+
+(Note that git-annex had a bug that caused v9 to upgrade to v10
+without waiting the year it was supposed to. That bug is why your v9 repo
+upgraded. That was fixed in today's git-annex release.)
+"""]]

diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_1_be44453dee893cc99759f90e660c0a66._comment b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_1_be44453dee893cc99759f90e660c0a66._comment
new file mode 100644
index 0000000000..91d49307d8
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs/comment_1_be44453dee893cc99759f90e660c0a66._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="kdm9"
+ avatar="http://cdn.libravatar.org/avatar/b7b736335a0e9944a8169a582eb4c43d"
+ subject="comment 1"
+ date="2022-09-27T17:49:53Z"
+ content="""
+(many apologies, I buggered up the markdown formatting of the following section. Fixed below)
+
+### What steps will reproduce the problem?
+
+(approximately)
+
+```
+git init && git annex init --version 10
+(add some large file, commit)
+git annex sync
+git status # hangs forever
+git annex status # hangs forever
+git annex info # actually works, and produces typical output
+git diff path/to/normal-file.txt # also hangs
+git annex version # actually works, and produces typical output
+```
+
+"""]]

diff --git a/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs.mdwn b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs.mdwn
new file mode 100644
index 0000000000..d111c58ccd
--- /dev/null
+++ b/doc/bugs/infinite_hang_on_git_status_with_v10___38___nfs.mdwn
@@ -0,0 +1,62 @@
+### Please describe the problem.
+
+There appears to be some locking-related pain with git annex v10 on NFS.
+
+Specifically, git status, git annex status, and seemingly everything that uses git-annex filter-process will hang forever.
+
+### What steps will reproduce the problem?
+
+(approximately)
+```
+git init && git annex init --version 10
+(add some large file, commit)
+git annex sync
+git status # hangs forever
+git annex status # hangs forever
+git annex info # actually works, and produces typical output
+git diff path/to/normal-file.txt # also hangs
+git annex version # actually works, and produces typical output
+```
+
+### What version of git-annex are you using? On what operating system?
+
+Git annex installed from the latest standalone amd64 tarball. I verified that both `which git` and `which git-annex` point to the scripts/binaries in that tarball.
+
+```
+$ git annex version
+git-annex version: 10.20220725-g9ac72bff2
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.26 DAV-1.3.4 feed-1.3.0.1 ghc-8.8.4 http-client-0.6.4.1 persistent-sqlite-2.10.6.2 torrent-10000.1.1 uuid-1.3.13 yesod-1.6.1.0
+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 X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg 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
+```
+
+Running Ubuntu 20.04, with ~/ (where binaries are) and /workspaces (where the repo is) on NFS. `mount -v` shows the following (clipped and IPs obscured)
+
+```
+srv:/path on /workspaces type nfs4 (rw,noatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=XXXX,local_lock=none,addr=XXXX)           
+```
+
+.git/config contains (anonymised)
+```
+[annex]
+        uuid = UUID_HERE
+        version = 10
+        pidlock = true
+```
+
+
+### Please provide any additional information below.
+
+
+As a workaround, I deleted all files from .git/annex EXCEPT for the objects directory, then did `git annex init --version=9`, and reset the UUID to what it was before. I then ran git annex fsck, and it all seemed to function correctly with no hangs. But, a few commands later, I noticed we were back at version=10, and the problem recurred. I set `annex.autoupgraderepository = false`, again nuked .git/annex, set version=8 this time in the config file and with git annex init --version 8 and it seems were good and stable for now.
+
+
+### 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)
+
+A great deal! We're managing tens of TB of plant genomics data with git annex, and it's a life saver, so many many thanks Joey et al. I know NFS is a bit of an edge case in git-annex land, but for the majority of git-annex's scientific users, NFS is all we have.
+

diff --git a/doc/news/version_10.20220504.mdwn b/doc/news/version_10.20220504.mdwn
deleted file mode 100644
index 21c729a9e6..0000000000
--- a/doc/news/version_10.20220504.mdwn
+++ /dev/null
@@ -1,17 +0,0 @@
-git-annex 10.20220504 released with [[!toggle text="these changes"]]
-[[!toggleable text="""  * Ignore annex.numcopies set to 0 in gitattributes or git config,
-    or by git-annex numcopies or by --numcopies, since that
-    configuration would make git-annex easily lose data.
-    Same for mincopies.
-  * assistant: When annex.autocommit is set, notice commits that
-    the user makes manually, and push them out to remotes promptly.
-  * multicast: Support uftp 5.0 by switching from aes256-cbc to
-    aes256-gcm.
-  * Fix test failure on NFS when cleaning up gpg temp directory.
-  * Fix a build failure with ghc 9.2.2.
-    Thanks, gnezdo for the patch.
-  * rsync 3.2.4 broke backwards-compatability by preventing exposing
-    filenames to the shell. Made the rsync and gcrypt special remotes
-    detect this and disable shellescape. Closes: #[1010397](http://bugs.debian.org/1010397)
-  * repair: Avoid treating refs/annex/last-index or other refs that
-    are not commit objects as evidence of repository corruption."""]]
\ No newline at end of file
diff --git a/doc/news/version_10.20220927.mdwn b/doc/news/version_10.20220927.mdwn
new file mode 100644
index 0000000000..a4c8938a24
--- /dev/null
+++ b/doc/news/version_10.20220927.mdwn
@@ -0,0 +1,45 @@
+git-annex 10.20220927 released with [[!toggle text="these changes"]]
+[[!toggleable text="""  * Fix a bug in the last release that caused v8 repositories to upgrade
+    immediately to v10, rather than taking the scheduled 1 year to do so.
+  * annex.diskreserve default increased from 1 mb to 100 mb.
+  * Include the assistant and webapp when building with cabal 3.4.1.0.
+  * Merged the webapp build flag into the assistant build flag.
+  * Optimise linker in linux standalone tarballs.
+  * Fix crash importing from a directory special remote that contains
+    a broken symlink.
+  * When accessing a git remote over http needs a git credential
+    prompt for a password, cache it for the lifetime of the git-annex
+    process, rather than repeatedly prompting.
+  * Use curl for downloads from git remotes when annex.url-options is set.
+  * Fix a reversion that made dead keys not be skipped when operating on
+    all keys via --all or in a bare repo.
+    (Introduced in version 8.20200720)
+  * vicfg: Include mincopies configuration.
+  * Improve handling of directory special remotes with importtree=yes whose
+    ignoreinode setting has been changed. When getting a file from such a
+    remote, accept the content that would have been accepted with the
+    previous ignoreinode setting.
+  * directory, adb: Fixed a bug with importtree=yes and multiple files
+    in the special remote have the same content, that caused it to
+    refuse to get a file from the special remote, incorrectly complaining
+    that it had changed, due to only accepting the inode+mtime of one file
+    (that was since modified or deleted) and not accepting the inode+mtime
+    of other duplicate files.
+  * Fix a reversion that prevented git-annex from working in a
+    repository when --git-dir or GIT\_DIR is specified to relocate the git
+    directory to somewhere else.
+    (Introduced in version 10.20220525)
+  * Improved handling of --time-limit when combined with -J
+  * Fix updating git index file after getting an unlocked file
+    when annex.stalldetection is set.
+  * restage: New git-annex command, handles restaging unlocked files.
+  * test: Added --test-with-git-config option.
+  * Run annex.freezecontent-command and annex.thawcontent-command
+    when on a crippled filesystem.
+    Thanks, Reiko Asakura
+  * enable-tor: Fix breakage caused by git's fix for CVE-2022-24765.
+  * Let GIT\_DIR and --git-dir override git's protection against operating
+    in a repository owned by another user.
+  * p2p: Pass wormhole the --appid option before the receive/send command,
+    as it does not accept that option after the command
+  * Support "inbackend" in preferred content expressions."""]]
\ No newline at end of file

diff --git a/doc/install/Linux_standalone.mdwn b/doc/install/Linux_standalone.mdwn
index ffb26aa388..4d4bef7210 100644
--- a/doc/install/Linux_standalone.mdwn
+++ b/doc/install/Linux_standalone.mdwn
@@ -42,7 +42,7 @@ The arm autobuilder runs daily (sun permitting), and is hosted by [[Joey]].
 
 * arm: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-armel.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/armel/))
 
-The arm64 autobuilder runs only intermittently. [[Better hosting needed.|todo/arm64_autobuilder]].
+The arm64 autobuilder runs only intermittently. Better hosting needed.
 
 * arm64: [download tarball](https://downloads.kitenet.net/git-annex/autobuild/armel/git-annex-standalone-arm64.tar.gz) ([build logs](https://downloads.kitenet.net/git-annex/autobuild/arm64/))
 

diff --git a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
index ac95ac2b6c..eb115d29b4 100644
--- a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
+++ b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
@@ -17,6 +17,9 @@ The following steps are tested on Windows 10 21h1 with Ubuntu 20 and are designe
     * `git config annex.freezecontent-command 'wsl-freezecontent %path'`
     * `git config annex.thawcontent-command 'wsl-thawcontent %path'`
 
+<details>
+<summary>wsl-freezecontent</summary>
+
 ```
 #!/usr/bin/env bash
 
@@ -40,7 +43,10 @@ if [ "$?" -ne 0 ]; then
 fi
 
 ```
+</details>
 
+<details>
+<summary>wsl-thawcontent</summary>
 
 ```
 #!/usr/bin/env bash
@@ -61,106 +67,12 @@ if [ "$?" -ne 0 ]; then
 fi
 
 ```
+</details>
 
 ** Patches **
 
-This patch allows permissions and freeze/thaw hooks to run on a crippled file system.
-
-```
-From 7f3da0dda841bf73645809d3919cff2a37cb21de Mon Sep 17 00:00:00 2001
-From: Reiko Asakura <asakurareiko@protonmail.ch>
-Date: Sat, 23 Oct 2021 17:14:27 -0400
-Subject: [PATCH 2/2] Allow perms on crippled filesystem
-
----
- Annex/Perms.hs | 22 +++++++++-------------
- 1 file changed, 9 insertions(+), 13 deletions(-)
-
-diff --git a/Annex/Perms.hs b/Annex/Perms.hs
-index 6681da7e0..e0c323d05 100644
---- a/Annex/Perms.hs
-+++ b/Annex/Perms.hs
-@@ -61,7 +61,7 @@ setAnnexPerm :: Bool -> RawFilePath -> Annex ()
- setAnnexPerm = setAnnexPerm' Nothing
- 
- setAnnexPerm' :: Maybe ([FileMode] -> FileMode -> FileMode) -> Bool -> RawFilePath -> Annex ()
--setAnnexPerm' modef isdir file = unlessM crippledFileSystem $
-+setAnnexPerm' modef isdir file =
- 	withShared $ liftIO . go
-   where
- 	go GroupShared = void $ tryIO $ modifyFileMode file $ modef' $
-@@ -89,7 +89,7 @@ resetAnnexFilePerm = resetAnnexPerm False
-  - usual modes.
-  -}
- resetAnnexPerm :: Bool -> RawFilePath -> Annex ()
--resetAnnexPerm isdir file = unlessM crippledFileSystem $ do
-+resetAnnexPerm isdir file = do
- 	defmode <- liftIO defaultFileMode
- 	let modef moremodes _oldmode = addModes moremodes defmode
- 	setAnnexPerm' (Just modef) isdir file
-@@ -154,7 +154,7 @@ createWorkTreeDirectory dir = do
-  - that happens with write permissions.
-  -}
- freezeContent :: RawFilePath -> Annex ()
--freezeContent file = unlessM crippledFileSystem $
-+freezeContent file =
- 	withShared $ \sr -> freezeContent' sr file
- 
- freezeContent' :: SharedRepository -> RawFilePath -> Annex ()
-@@ -199,14 +199,12 @@ freezeContent'' sr file rv = do
-  - write permissions are ignored.
-  -}
- checkContentWritePerm :: RawFilePath -> Annex (Maybe Bool)
--checkContentWritePerm file = ifM crippledFileSystem
--	( return (Just True)
--	, do
-+checkContentWritePerm file =
-+	do
- 		rv <- getVersion
- 		hasfreezehook <- hasFreezeHook
- 		withShared $ \sr -> liftIO $
- 			checkContentWritePerm' sr file rv hasfreezehook
--	)
- 
- checkContentWritePerm' :: SharedRepository -> RawFilePath -> Maybe RepoVersion -> Bool -> IO (Maybe Bool)
- checkContentWritePerm' sr file rv hasfreezehook
-@@ -252,10 +250,8 @@ thawContent' sr file = do
-  - crippled filesystem, the file may be frozen, so try to thaw its
-  - permissions. -}
- thawPerms :: Annex () -> Annex () -> Annex ()
--thawPerms a hook = ifM crippledFileSystem
--	( void (tryNonAsync a)
--	, hook >> a
--	)
-+thawPerms a hook =
-+	hook >> a
- 
- {- Blocks writing to the directory an annexed file is in, to prevent the
-  - file accidentally being deleted. However, if core.sharedRepository
-@@ -263,7 +259,7 @@ thawPerms a hook = ifM crippledFileSystem
-  - file.
-  -}
- freezeContentDir :: RawFilePath -> Annex ()
--freezeContentDir file = unlessM crippledFileSystem $ do
-+freezeContentDir file = do
- 	fastDebug "Annex.Perms" ("freezing content directory " ++ fromRawFilePath dir)
- 	withShared go
- 	freezeHook dir
-@@ -287,7 +283,7 @@ createContentDir dest = do
- 	unlessM (liftIO $ R.doesPathExist dir) $
- 		createAnnexDirectory dir 
- 	-- might have already existed with restricted perms
--	unlessM crippledFileSystem $ do
-+	do
- 		thawHook dir
- 		liftIO $ allowWrite dir
-   where
--- 
-2.30.2
-
-```
-
-This patch allows `git annex fix` on a crippled file system.
+<details>
+<summary>This patch allows `git annex fix` on a crippled file system.</summary>
 
 ```
 From 65fe6e362dfbf2f54c8da5ca17c59af26de5ff83 Mon Sep 17 00:00:00 2001
@@ -189,10 +101,14 @@ index 39853c894..2d66c1461 100644
 2.30.2
 
 ```
+</details>
 
 ** Usage tips **
 
-* Symlinks are invalid in Windows if created before the target file exists, such as after `git annex add` or `git annex get`. This can be fixed by recreating them with any method, such as delete them and `git checkout`. Below is a sample script.
+* Symlinks are invalid in Windows if created before the target file exists, such as after `git annex add` or `git annex get`. This can be fixed by recreating them with any method, such as delete them and `git checkout`.
+
+<details>
+<summary>Sample script to recreate all symlinks under the current directory</summary>
 
 ```
 #!/usr/bin/env python3
@@ -211,6 +127,7 @@ def do(p):
 
 do(pathlib.Path('.'))
 ```
+</details>
 
 * Sometimes there will SQLite errors using multiple jobs but retrying will work most of the time.
 

diff --git a/Annex/FileMatcher.hs b/Annex/FileMatcher.hs
index 7a876debcc..8f09658994 100644
--- a/Annex/FileMatcher.hs
+++ b/Annex/FileMatcher.hs
@@ -180,7 +180,7 @@ preferredContentKeyedTokens pcd =
 	, ValueToken "copies" (usev limitCopies)
 	, ValueToken "lackingcopies" (usev $ limitLackingCopies False)
 	, ValueToken "approxlackingcopies" (usev $ limitLackingCopies True)
-	, ValueToken "inbacked" (usev limitInBackend)
+	, ValueToken "inbackend" (usev limitInBackend)
 	, ValueToken "metadata" (usev limitMetaData)
 	, ValueToken "inallgroup" (usev $ limitInAllGroup $ getGroupMap pcd)
 	] ++ commonKeyedTokens
diff --git a/CHANGELOG b/CHANGELOG
index 9a202ccaf6..6cecf4d250 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,4 +1,4 @@
-git-annex (10.20220823) UNRELEASED; urgency=medium
+git-annex (10.20220927) UNRELEASED; urgency=medium
 
   * Fix a bug in the last release that caused v8 repositories to upgrade
     immediately to v10, rather than taking the scheduled 1 year to do so.
@@ -43,6 +43,7 @@ git-annex (10.20220823) UNRELEASED; urgency=medium
     in a repository owned by another user.
   * p2p: Pass wormhole the --appid option before the receive/send command,
     as it does not accept that option after the command
+  * Support "inbackend" in preferred content expressions.
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Aug 2022 15:03:04 -0400
 
diff --git a/doc/git-annex-preferred-content/comment_6_f10a0c185fa2f2b4b8ec9fceaed6e8e1._comment b/doc/git-annex-preferred-content/comment_6_f10a0c185fa2f2b4b8ec9fceaed6e8e1._comment
new file mode 100644
index 0000000000..11d9c25844
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_6_f10a0c185fa2f2b4b8ec9fceaed6e8e1._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-26T19:53:52Z"
+ content="""
+@rinomizu5 congrats, you found a bug!
+
+I've fixed this, so you'll want to upgrade to version 10.20220927 when
+it's released tomorrow.
+"""]]
diff --git a/git-annex.cabal b/git-annex.cabal
index bea054e907..6b902b116d 100644
--- a/git-annex.cabal
+++ b/git-annex.cabal
@@ -1,5 +1,5 @@
 Name: git-annex
-Version: 10.20220822
+Version: 10.20220927
 Cabal-Version: 1.12
 License: AGPL-3
 Maintainer: Joey Hess <id@joeyh.name>

diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_3_9fa2fb82ae3d17a77a9645870e1e12e5._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_3_9fa2fb82ae3d17a77a9645870e1e12e5._comment
new file mode 100644
index 0000000000..3a688a3f5a
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_3_9fa2fb82ae3d17a77a9645870e1e12e5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-26T18:51:25Z"
+ content="""
+Fixed `git-annex enable-tor`
+
+The `git-annex p2p --pair` failing is unrelated. It seems that
+`wormhole` has either changed its syntax for --appid, or git-annex has
+never passed --appid to it correctly. I've fixed it to use the current
+syntax.
+"""]]

diff --git a/doc/backends.mdwn b/doc/backends.mdwn
index 29b1820311..32267d17dd 100644
--- a/doc/backends.mdwn
+++ b/doc/backends.mdwn
@@ -1,10 +1,8 @@
-When a file is annexed, a [[key|internals/key_format]] is generated from
-its content and/or filesystem metadata. The file checked into git symlinks
-to the key. This key can later be used to retrieve the file's content (its
-value).
-
-Multiple key-value backends are supported, and a single repository
-can use different ones for different files. 
+The "backend" in git-annex specifies how a key is generated from a file's
+content and/or filesystem metadata. Most backends are different kinds of
+hashes. A single repository can use different backends for different files.
+The [[key|internals/key_format]] includes the backend that is used for that
+key.
 
 ## configuring which backend to use
 
@@ -47,7 +45,8 @@ in `.gitattributes`:
   platforms.
 * `BLAKE2S160`, `BLAKE2S224`, `BLAKE2S256`
   `BLAKE2S160E`, `BLAKE2S224E`, `BLAKE2S256E`
-  -- Fast [Blake2 hash](https://blake2.net/) variants optimised for 32 bit
+  -- Fas:w
+  t [Blake2 hash](https://blake2.net/) variants optimised for 32 bit
   platforms.
 * `BLAKE2BP512`, `BLAKE2BP512E`
   -- Fast [Blake2 hash](https://blake2.net/) variants optimised for
@@ -74,7 +73,7 @@ content of an annexed file remains unchanged.
   URL; for long URLs, part of the URL may be represented by a checksum.
   The URL key may contain `&` characters; be sure to quote the key if
   passing it to a shell script.  The URL-backend key is distinct from URLs/URIs
-  that may be attached to a key (from any backend) indicating the key's location
+  that may be attached to a key (using any backend) indicating the key's location
   on the web or in one of [[special_remotes]].
 * `GIT` -- This is used internally by git-annex when exporting trees
   containing files stored in git, rather than git-annex. It represents a
@@ -110,5 +109,3 @@ for [[security_reasons|security/CVE-2018-10857_and_CVE-2018-10859]].
 Note that the various 512 and 384 length hashes result in long paths,
 which are known to not work on Windows. If interoperability on Windows is a
 concern, avoid those.
-
-See also: [[git-annex-examinekey]]
diff --git a/doc/git-annex-backends.mdwn b/doc/git-annex-backends.mdwn
new file mode 100644
index 0000000000..86205eaebc
--- /dev/null
+++ b/doc/git-annex-backends.mdwn
@@ -0,0 +1,24 @@
+# NAME
+
+git-annex-backends - key/value backends for git-annex
+
+# DESCRIPTION
+
+The "backend" in git-annex controls how a key is generated from a file's
+content and/or filesystem metadata. Most backends are different kinds of
+hashes. A single repository can use different backends for different files.
+
+For a list of available backends, see `git-annex version`. For more
+details, see <https://git-annex.branchable.com/backends/>
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+<http://git-annex.branchable.com/>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex-migrate.mdwn b/doc/git-annex-migrate.mdwn
index b05991930d..18e9f2c89e 100644
--- a/doc/git-annex-migrate.mdwn
+++ b/doc/git-annex-migrate.mdwn
@@ -57,6 +57,8 @@ it's best to run migrate in all of them.
 
 [[git-annex-upgrade]](1)
 
+[[git-annex-backend]](1)
+
 # AUTHOR
 
 Joey Hess <id@joeyh.name>
diff --git a/doc/git-annex-preferred-content.mdwn b/doc/git-annex-preferred-content.mdwn
index 5972ab7f3a..f28385dc40 100644
--- a/doc/git-annex-preferred-content.mdwn
+++ b/doc/git-annex-preferred-content.mdwn
@@ -99,11 +99,13 @@ elsewhere to allow removing it).
   Like lackingcopies, but does not look at .gitattributes annex.numcopies
   settings. This makes it significantly faster.
 
-* `inbackend=name`
+* `inbackend=backendname`
 
   Matches only files whose content is stored using the specified key-value
   backend.
 
+  See [[git-annex-backends]](1) for information about available backends.
+
 * `securehash`
 
   Matches only files whose content is hashed using a cryptographically
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 5a8d7af943..5eca6600c8 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -792,7 +792,8 @@ repository, using [[git-annex-config]]. See its man page for a list.)
 * `annex.backend`
 
   Name of the default key-value backend to use when adding new files
-  to the repository.
+  to the repository. See [[git-annex-backends]](1) for information about
+  available backends.
 
   This is overridden by annex annex.backend configuration in the
   .gitattributes files, and by the --backend option.
@@ -1908,7 +1909,9 @@ Remotes are configured using these settings in `.git/config`.
 The key-value backend used when adding a new file to the annex can be
 configured on a per-file-type basis via `.gitattributes` files. In the file,
 the `annex.backend` attribute can be set to the name of the backend to
-use. For example, this here's how to use the WORM backend by default,
+use. (See [[git-annex-backends]](1) for information about
+available backends.)
+For example, this here's how to use the WORM backend by default,
 but the SHA256E backend for ogg files:
 
 	* annex.backend=WORM
diff --git a/git-annex.cabal b/git-annex.cabal
index e3234ec4d7..bea054e907 100644
--- a/git-annex.cabal
+++ b/git-annex.cabal
@@ -46,6 +46,7 @@ Extra-Source-Files:
   doc/git-annex-addurl.mdwn
   doc/git-annex-adjust.mdwn
   doc/git-annex-assistant.mdwn
+  doc/git-annex-backends.mdwn
   doc/git-annex-calckey.mdwn
   doc/git-annex-checkpresentkey.mdwn
   doc/git-annex-config.mdwn
@@ -109,6 +110,7 @@ Extra-Source-Files:
   doc/git-annex-renameremote.mdwn
   doc/git-annex-repair.mdwn
   doc/git-annex-required.mdwn
+  doc/git-annex-restage.mdwn
   doc/git-annex-resolvemerge.mdwn
   doc/git-annex-rmurl.mdwn
   doc/git-annex-schedule.mdwn

diff --git a/CHANGELOG b/CHANGELOG
index 7f2a6773f3..9a202ccaf6 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -41,6 +41,8 @@ git-annex (10.20220823) UNRELEASED; urgency=medium
   * enable-tor: Fix breakage caused by git's fix for CVE-2022-24765.
   * Let GIT_DIR and --git-dir override git's protection against operating
     in a repository owned by another user.
+  * p2p: Pass wormhole the --appid option before the receive/send command,
+    as it does not accept that option after the command
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Aug 2022 15:03:04 -0400
 
diff --git a/Utility/MagicWormhole.hs b/Utility/MagicWormhole.hs
index cc189b6252..a4128d1d5c 100644
--- a/Utility/MagicWormhole.hs
+++ b/Utility/MagicWormhole.hs
@@ -119,7 +119,7 @@ sendFile f (CodeObserver observer) ps = do
 			(findcode ph herr)
 		return (inout || inerr)
   where
-	p = wormHoleProcess (Param "send" : ps ++ [File f])
+	p = wormHoleProcess (ps ++ [Param "send", File f])
 	findcode ph h = findcode' =<< getwords ph h []
 	findcode' [] = return False
 	findcode' (w:ws) = case mkCode w of
@@ -140,12 +140,12 @@ receiveFile f (CodeProducer producer) ps = runWormHoleProcess p $ \hin _hout _he
 	hFlush hin
 	return True
   where
-	p = wormHoleProcess $
+	p = wormHoleProcess $ ps ++
 		[ Param "receive"
 		, Param "--accept-file"
 		, Param "--output-file"
 		, File f
-		] ++ ps
+		]
 
 wormHoleProcess :: WormHoleParams -> CreateProcess
 wormHoleProcess = proc "wormhole" . toCommand
diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn b/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
index bdf2701c24..586650e5de 100644
--- a/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
@@ -78,3 +78,5 @@ p2p: 1 failed
 ### 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)
 
 git annex has been awesome so far in helping track and backup my data, also for allowing me to output podcasts/audiobooks to a small mp3 player, as well as ebooks and pdfs to a kindle paper ewhite, which has made using my ereader no longer an inconvinient endeavour 
+
+> [[fixed|done]] --[[Joey]]

diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
index 53efebbf49..289688d5bb 100644
--- a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
@@ -10,4 +10,8 @@ I can reproduce this by running eg:
 	joey@darkstar:~/tmp/torrepo>su -c "git-annex --debug enable-tor 1000"
 	Password:
 	git-annex: This can only be run in a git-annex repository.
+
+This was broken by git's security fix for CVE-2022-24765. Now when the root
+process tries to run `git config --list`, git does not display the local
+.git/config, because it is owned by another user.
 """]]
diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
new file mode 100644
index 0000000000..6261bfc7f2
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-26T17:24:23Z"
+ content="""
+Note that when git-annex uses sudo to gain root, git does not behave that
+way. But it can also use su or other methods.
+"""]]

diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
index 289688d5bb..53efebbf49 100644
--- a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
@@ -10,8 +10,4 @@ I can reproduce this by running eg:
 	joey@darkstar:~/tmp/torrepo>su -c "git-annex --debug enable-tor 1000"
 	Password:
 	git-annex: This can only be run in a git-annex repository.
-
-This was broken by git's security fix for CVE-2022-24765. Now when the root
-process tries to run `git config --list`, git does not display the local
-.git/config, because it is owned by another user.
 """]]
diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
deleted file mode 100644
index 6261bfc7f2..0000000000
--- a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
+++ /dev/null
@@ -1,8 +0,0 @@
-[[!comment format=mdwn
- username="joey"
- subject="""comment 2"""
- date="2022-09-26T17:24:23Z"
- content="""
-Note that when git-annex uses sudo to gain root, git does not behave that
-way. But it can also use su or other methods.
-"""]]

diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
new file mode 100644
index 0000000000..6261bfc7f2
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_2_5df90e5ffbd3f089a0f640d4a5b85a1c._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2022-09-26T17:24:23Z"
+ content="""
+Note that when git-annex uses sudo to gain root, git does not behave that
+way. But it can also use su or other methods.
+"""]]

diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
new file mode 100644
index 0000000000..289688d5bb
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work/comment_1_35c33ae1d69382a03c94f4a20ec22f7e._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-26T17:20:05Z"
+ content="""
+I can reproduce this by running eg:
+
+	joey@darkstar:~/tmp/torrepo>git-annex init
+	init  ok
+	joey@darkstar:~/tmp/torrepo>su -c "git-annex --debug enable-tor 1000"
+	Password:
+	git-annex: This can only be run in a git-annex repository.
+
+This was broken by git's security fix for CVE-2022-24765. Now when the root
+process tries to run `git config --list`, git does not display the local
+.git/config, because it is owned by another user.
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index ca9d6ed2f4..177e10e28b 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -35,6 +35,9 @@ git-annex (10.20220823) UNRELEASED; urgency=medium
     when annex.stalldetection is set.
   * restage: New git-annex command, handles restaging unlocked files.
   * test: Added --test-with-git-config option.
+  * Run annex.freezecontent-command and annex.thawcontent-command
+    when on a crippled filesystem.
+    Thanks, Reiko Asakura
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Aug 2022 15:03:04 -0400
 
diff --git a/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn
index 22b1240c9e..ea6ffb1a7b 100644
--- a/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn
+++ b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn
@@ -72,3 +72,5 @@ index 6681da7e0..69e344452 100644
 2.30.2
 
 ```
+
+> [[done]] --[[Joey]]
diff --git a/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs/comment_1_b943081483e4f1f9897b214004d48493._comment b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs/comment_1_b943081483e4f1f9897b214004d48493._comment
new file mode 100644
index 0000000000..c1abde42f3
--- /dev/null
+++ b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs/comment_1_b943081483e4f1f9897b214004d48493._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-26T17:01:33Z"
+ content="""
+Thank you for this patch. I've applied it.
+"""]]

diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index 7b4d3f3982..5a8d7af943 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -1279,6 +1279,9 @@ repository, using [[git-annex-config]]. See its man page for a list.)
   In the command line, %path is replaced with the file or directory to
   operate on.
 
+  (When annex.crippledfilesystem is set, git-annex will not try to
+  remove/restore the write bit, but it will still run these hooks.)
+
 * `annex.tune.objecthash1`, `annex.tune.objecthashlower`, `annex.tune.branchhash1`
 
   These can be passed to `git annex init` to tune the repository.

diff --git a/Upgrade.hs b/Upgrade.hs
index 2073b1bec0..244050444f 100644
--- a/Upgrade.hs
+++ b/Upgrade.hs
@@ -74,31 +74,24 @@ needsUpgrade v
 		Left ex -> err $ "Automatic upgrade exception! " ++ show ex
 
 upgrade :: Bool -> RepoVersion -> Annex Bool
-upgrade automatic destversion = do
-	startversion <- getVersion
-	(ok, newversion) <- go startversion
-	when (ok && newversion /= startversion) $
-		postupgrade newversion
-	return ok
+upgrade automatic destversion = go =<< getVersion
   where
 	go (Just v)
-		| v >= destversion = return (True, Just v)
+		| v >= destversion = return True
 		| otherwise = ifM upgradingRemote
 			( upgraderemote
 			, up v >>= \case
-				UpgradeSuccess -> go (Just (incrversion v) )
-				UpgradeFailed -> return (False, Just v)
-				UpgradeDeferred -> return (True, Just v)
+				UpgradeSuccess -> do
+					let v' = incrversion v
+					upgradedto v'
+					go (Just v')
+				UpgradeFailed -> return False
+				UpgradeDeferred -> return True
 			)
-	go Nothing = return (True, Nothing)
+	go Nothing = return True
 
 	incrversion v = RepoVersion (fromRepoVersion v + 1)
 
-	postupgrade newversion = ifM upgradingRemote
-		( reloadConfig
-		, maybe noop upgradedto newversion
-		)
-
 #ifndef mingw32_HOST_OS
 	up (RepoVersion 0) = Upgrade.V0.upgrade
 	up (RepoVersion 1) = Upgrade.V1.upgrade
@@ -121,15 +114,18 @@ upgrade automatic destversion = do
 	-- upgrading a git repo other than the current repo.
 	upgraderemote = do
 		rp <- fromRawFilePath <$> fromRepo Git.repoPath
-		gitAnnexChildProcess "upgrade"
+		ok <- gitAnnexChildProcess "upgrade"
 			[ Param "--quiet"
 			, Param "--autoonly"
 			]
 			(\p -> p { cwd = Just rp })
 			(\_ _ _ pid -> waitForProcess pid >>= return . \case
-				ExitSuccess -> (True, Nothing)
-				_ -> (False, Nothing)
+				ExitSuccess -> True
+				_ -> False
 			)
+		when ok
+			reloadConfig
+		return ok
 
 	upgradedto v = do
 		setVersion v
diff --git a/Upgrade/V9.hs b/Upgrade/V9.hs
index 124e285498..21c73fe5fb 100644
--- a/Upgrade/V9.hs
+++ b/Upgrade/V9.hs
@@ -40,12 +40,13 @@ upgrade automatic
 	 - and it is not safe for such to still be running after
 	 - this upgrade. -}
 	oldprocessesdanger = timeOfUpgrade (RepoVersion 9) >>= \case
-		Nothing -> pure True
 		Just t -> do
 			now <- liftIO getPOSIXTime
 			if now < t + 365*24*60*60
 				then return True
 				else assistantrunning
+		-- Initialized at v9, so no old process danger exists.
+		Nothing -> pure False
 
 	{- Skip upgrade when git-annex assistant (or watch) is running,
 	 - because these are long-running daemons that could conceivably
diff --git a/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn b/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn
index 023f8c694c..c9f294ed92 100644
--- a/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn
+++ b/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn
@@ -16,3 +16,4 @@ git config annex.version
 
 10.20220822 Linux
 
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment b/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment
index 552276d453..c9f786c0bd 100644
--- a/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment
+++ b/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment
@@ -8,7 +8,7 @@ which was included in version 10.20220822.
 
 I've reverted the commit as a first step. This means repos initialized
 at v9 will never autoupgrade to v10, which will need to be fixed
-somehow.
+somehow. (Update: Fixed that now.)
 
 Gonna need to make a git-annex release ASAP to get this fix out there.
 """]]

diff --git a/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment b/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment
new file mode 100644
index 0000000000..552276d453
--- /dev/null
+++ b/doc/bugs/v8_repo_auto_upgrades_to_v10/comment_1_446aa74f0b54918dc8737483e3e8564a._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-26T16:15:41Z"
+ content="""
+This was broken in [[!commit 0d2e3058ee01d55dc3b929ddf8e0573a95a2ca85]]
+which was included in version 10.20220822.
+
+I've reverted the commit as a first step. This means repos initialized
+at v9 will never autoupgrade to v10, which will need to be fixed
+somehow.
+
+Gonna need to make a git-annex release ASAP to get this fix out there.
+"""]]

diff --git a/Annex/PidLock.hs b/Annex/PidLock.hs
index ddc7529a2b..9b2adea4e8 100644
--- a/Annex/PidLock.hs
+++ b/Annex/PidLock.hs
@@ -127,5 +127,5 @@ runsGitAnnexChildProcessViaGit' r a = pidLockFile >>= \case
 		r' <- liftIO $ addGitEnv r v PidF.pidLockEnvValue
 		a r'
 #else
-runsGitAnnexChildProcessViaGit' r a = liftIO $ a r
+runsGitAnnexChildProcessViaGit' r a = a r
 #endif
diff --git a/doc/bugs/windows_ftbfs.mdwn b/doc/bugs/windows_ftbfs.mdwn
index ad2a39c739..77d3a8c926 100644
--- a/doc/bugs/windows_ftbfs.mdwn
+++ b/doc/bugs/windows_ftbfs.mdwn
@@ -40,3 +40,5 @@ Warning: Failed to decode module interface:
          Decoding failure: Invalid magic: e49ceb0f
 ...
 ```
+
+> [[fixed|done]] --[[Joey]]

diff --git a/doc/bugs/windows_ftbfs.mdwn b/doc/bugs/windows_ftbfs.mdwn
new file mode 100644
index 0000000000..ad2a39c739
--- /dev/null
+++ b/doc/bugs/windows_ftbfs.mdwn
@@ -0,0 +1,42 @@
+### Please describe the problem.
+
+Started to happen recently (0924):
+
+```shell
+(git)smaug:/mnt/datasets/datalad/ci/git-annex/builds/2022/09[master]git
+$> git grep -l 'Couldn.t match expected type '
+cron-20220924/build-windows.yaml-788-e26581b6-failed/1_build-package (1).txt
+cron-20220924/build-windows.yaml-788-e26581b6-failed/build-package/18_Build git-annex.txt
+cron-20220925/build-windows.yaml-790-e26581b6-failed/1_build-package (1).txt
+cron-20220925/build-windows.yaml-790-e26581b6-failed/build-package/18_Build git-annex.txt
+cron-20220926/build-windows.yaml-791-40917e42-failed/1_build-package (1).txt
+cron-20220926/build-windows.yaml-791-40917e42-failed/build-package/18_Build git-annex.txt
+pr-133/build-windows.yaml-789-06e70ac7-failed/1_build-package (1).txt
+pr-133/build-windows.yaml-789-06e70ac7-failed/build-package/18_Build git-annex.txt
+```
+
+
+
+```
+Annex\PidLock.hs:130:48: error:
+    * Couldn't match expected type `IO a' with actual type `Annex a'
+    * In the second argument of `($)', namely `a r'
+      In the expression: liftIO $ a r
+      In an equation for runsGitAnnexChildProcessViaGit':
+          runsGitAnnexChildProcessViaGit' r a = liftIO $ a r
+    * Relevant bindings include
+        a :: Repo -> Annex a (bound at Annex\PidLock.hs:130:35)
+        runsGitAnnexChildProcessViaGit' :: Repo
+                                           -> (Repo -> Annex a) -> Annex a
+          (bound at Annex\PidLock.hs:130:1)
+    |
+130 | runsGitAnnexChildProcessViaGit' r a = liftIO $ a r
+
+    |                                                ^^^
+
+
+Warning: Failed to decode module interface:
+         D:\a\git-annex\git-annex\.stack-work\dist\274b403a\build\git-annex\git-annex-tmp\Annex.hi
+         Decoding failure: Invalid magic: e49ceb0f
+...
+```

diff --git a/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_14_45b1da34ec60d6322477edfd6a3a2bba._comment b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_14_45b1da34ec60d6322477edfd6a3a2bba._comment
new file mode 100644
index 0000000000..0d14328489
--- /dev/null
+++ b/doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_14_45b1da34ec60d6322477edfd6a3a2bba._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 14"
+ date="2022-09-25T19:43:31Z"
+ content="""
+Either of these changes causes the test case in comment 11 to hang indefinitely. Probably no way to fix these issues in general due to [[sqlite write locks aren't respected in WSL|https://github.com/microsoft/WSL/issues/2395]], but as things are currently everything works well enough.
+"""]]

diff --git a/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn
new file mode 100644
index 0000000000..22b1240c9e
--- /dev/null
+++ b/doc/todo/__91__PATCH__93___Run_freeze__47__thaw_hooks_on_crippled_fs.mdwn
@@ -0,0 +1,74 @@
+This patch allows hooks to be run in WSL1 for a repo created on an NTFS volume but I think it also applies in general.
+
+```
+From d4587806d8fd1ea767a8effc06edc1a4e10f5bca Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Sun, 25 Sep 2022 15:21:24 -0400
+Subject: [PATCH] Run freeze and thaw hooks on crippled filesystems
+
+The user sets these hooks deliberately so they should always be run. For
+example this allows hooks to be used to manage file permissions on NTFS
+volumes in WSL1.
+---
+ Annex/Perms.hs | 14 +++++++-------
+ 1 file changed, 7 insertions(+), 7 deletions(-)
+
+diff --git a/Annex/Perms.hs b/Annex/Perms.hs
+index 6681da7e0..69e344452 100644
+--- a/Annex/Perms.hs
++++ b/Annex/Perms.hs
+@@ -154,7 +154,7 @@ createWorkTreeDirectory dir = do
+  - that happens with write permissions.
+  -}
+ freezeContent :: RawFilePath -> Annex ()
+-freezeContent file = unlessM crippledFileSystem $
++freezeContent file =
+ 	withShared $ \sr -> freezeContent' sr file
+ 
+ freezeContent' :: SharedRepository -> RawFilePath -> Annex ()
+@@ -163,7 +163,7 @@ freezeContent' sr file = freezeContent'' sr file =<< getVersion
+ freezeContent'' :: SharedRepository -> RawFilePath -> Maybe RepoVersion -> Annex ()
+ freezeContent'' sr file rv = do
+ 	fastDebug "Annex.Perms" ("freezing content " ++ fromRawFilePath file)
+-	go sr
++	unlessM crippledFileSystem $ go sr
+ 	freezeHook file
+   where
+ 	go GroupShared = if versionNeedsWritableContentFiles rv
+@@ -253,7 +253,7 @@ thawContent' sr file = do
+  - permissions. -}
+ thawPerms :: Annex () -> Annex () -> Annex ()
+ thawPerms a hook = ifM crippledFileSystem
+-	( void (tryNonAsync a)
++	( hook >> void (tryNonAsync a)
+ 	, hook >> a
+ 	)
+ 
+@@ -263,9 +263,9 @@ thawPerms a hook = ifM crippledFileSystem
+  - file.
+  -}
+ freezeContentDir :: RawFilePath -> Annex ()
+-freezeContentDir file = unlessM crippledFileSystem $ do
++freezeContentDir file = do
+ 	fastDebug "Annex.Perms" ("freezing content directory " ++ fromRawFilePath dir)
+-	withShared go
++	unlessM crippledFileSystem $ withShared go
+ 	freezeHook dir
+   where
+ 	dir = parentDir file
+@@ -287,9 +287,9 @@ createContentDir dest = do
+ 	unlessM (liftIO $ R.doesPathExist dir) $
+ 		createAnnexDirectory dir 
+ 	-- might have already existed with restricted perms
+-	unlessM crippledFileSystem $ do
++	do
+ 		thawHook dir
+-		liftIO $ allowWrite dir
++		unlessM crippledFileSystem $ liftIO $ allowWrite dir
+   where
+ 	dir = parentDir dest
+ 
+-- 
+2.30.2
+
+```

diff --git a/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn b/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn
new file mode 100644
index 0000000000..023f8c694c
--- /dev/null
+++ b/doc/bugs/v8_repo_auto_upgrades_to_v10.mdwn
@@ -0,0 +1,18 @@
+### Please describe the problem.
+
+v8 repo automatically upgrades to v10 which is contrary to what the changelog states here [[news/version_10.20220822]].
+
+### What steps will reproduce the problem?
+
+```
+git init
+git annex init --version 8
+git config annex.version
+git annex info > /dev/null
+git config annex.version
+```
+
+### What version of git-annex are you using? On what operating system?
+
+10.20220822 Linux
+

diff --git a/doc/todo/windows_support.mdwn b/doc/todo/windows_support.mdwn
index e2ea77a613..eb498e2aa4 100644
--- a/doc/todo/windows_support.mdwn
+++ b/doc/todo/windows_support.mdwn
@@ -131,6 +131,6 @@ Seems like this would need Windows 10.
 > > > > But here's a bug about sqlite in WSL:
 > > > > [[bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol]] --[[Joey]]
 
-## update Oct 2021:
+## update Sept 2022:
 
 Git-annex has become more reliable on WSL1 recently, see [[tips/Using_git-annex_on_NTFS_with_WSL1]].

diff --git a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
index bd39dd5b79..ac95ac2b6c 100644
--- a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
+++ b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
@@ -13,48 +13,54 @@ The following steps are tested on Windows 10 21h1 with Ubuntu 20 and are designe
     * If the repository is created by cloning, create local git-annex branch from the remote branch and remove the origin remote before `git annex init`.
     * Set `git config annex.crippledfilesystem true` immediately after `git annex init`.
     * Add the origin remote back if it was previously removed.
-* Safety of locked files will require these settings and scripts
+* Safety of locked files will require these settings and scripts and the patch below.
+    * `git config annex.freezecontent-command 'wsl-freezecontent %path'`
     * `git config annex.thawcontent-command 'wsl-thawcontent %path'`
 
-            #!/usr/bin/env bash
-
-            if [ -f "$1" ]; then
-                PERM='(DE,WD,AD)'
-            elif [ -d "$1" ]; then
-                PERM='(DE,DC,WD,AD)'
-            else
-                exit 0
-            fi
+```
+#!/usr/bin/env bash
+
+if [ -f "$1" ]; then
+	if \[[ "$1" == *.git/annex/objects/* ]]; then
+		PERM='(DE,WD,AD)'
+	else
+		PERM='(WD,AD)'
+	fi
+elif [ -d "$1" ]; then
+	PERM='(DE,DC,WD,AD)'
+else
+	exit 0
+fi
+
+OUTPUT="$(icacls.exe "$(wslpath -w "$1")" /deny "Authenticated Users:$PERM")"
+
+if [ "$?" -ne 0 ]; then
+	echo "$OUTPUT"
+	exit 1
+fi
 
-            OUTPUT="$(icacls.exe "$(wslpath -w "$1")" /grant "Authenticated Users:$PERM")"
+```
 
-            if [ "$?" -ne 0 ]; then
-                echo "$OUTPUT"
-                exit 1
-            fi
 
-    * `git config annex.freezecontent-command 'wsl-freezecontent %path'`
+```
+#!/usr/bin/env bash
 
-            #!/usr/bin/env bash
+if [ -f "$1" ]; then
+	PERM='(DE,WD,AD)'
+elif [ -d "$1" ]; then
+	PERM='(DE,DC,WD,AD)'
+else
+	exit 0
+fi
 
-            if [ -f "$1" ]; then
-                if \[[ "$1" == *.git/annex/objects/* ]]; then
-                    PERM='(DE,WD,AD)'
-                else
-                    PERM='(WD,AD)'
-                fi
-            elif [ -d "$1" ]; then
-                PERM='(DE,DC,WD,AD)'
-            else
-                exit 0
-            fi
+OUTPUT="$(icacls.exe "$(wslpath -w "$1")" /grant "Authenticated Users:$PERM")"
 
-            OUTPUT="$(icacls.exe "$(wslpath -w "$1")" /deny "Authenticated Users:$PERM")"
+if [ "$?" -ne 0 ]; then
+	echo "$OUTPUT"
+	exit 1
+fi
 
-            if [ "$?" -ne 0 ]; then
-                echo "$OUTPUT"
-                exit 1
-            fi
+```
 
 ** Patches **
 
@@ -188,21 +194,23 @@ index 39853c894..2d66c1461 100644
 
 * Symlinks are invalid in Windows if created before the target file exists, such as after `git annex add` or `git annex get`. This can be fixed by recreating them with any method, such as delete them and `git checkout`. Below is a sample script.
 
-		#!/usr/bin/env python3
+```
+#!/usr/bin/env python3
 
-		import pathlib
-		import os
+import pathlib
+import os
 
-		def do(p):
-			for c in list(p.iterdir()):
-				if c.is_symlink() and c.resolve().exists():
-					target = os.readlink(c) # use readlink here to get the relative link path
-					c.unlink()
-					c.symlink_to(target)
-				elif c.is_dir() and c.name != '.git':
-					do(c)
+def do(p):
+	for c in list(p.iterdir()):
+		if c.is_symlink() and c.resolve().exists():
+			target = os.readlink(c) # use readlink here to get the relative link path
+			c.unlink()
+			c.symlink_to(target)
+		elif c.is_dir() and c.name != '.git':
+			do(c)
 
-		do(pathlib.Path('.'))
+do(pathlib.Path('.'))
+```
 
 * Sometimes there will SQLite errors using multiple jobs but retrying will work most of the time.
 

diff --git a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
index 43f485ef2f..bd39dd5b79 100644
--- a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
+++ b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
@@ -56,6 +56,134 @@ The following steps are tested on Windows 10 21h1 with Ubuntu 20 and are designe
                 exit 1
             fi
 
+** Patches **
+
+This patch allows permissions and freeze/thaw hooks to run on a crippled file system.
+
+```
+From 7f3da0dda841bf73645809d3919cff2a37cb21de Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Sat, 23 Oct 2021 17:14:27 -0400
+Subject: [PATCH 2/2] Allow perms on crippled filesystem
+
+---
+ Annex/Perms.hs | 22 +++++++++-------------
+ 1 file changed, 9 insertions(+), 13 deletions(-)
+
+diff --git a/Annex/Perms.hs b/Annex/Perms.hs
+index 6681da7e0..e0c323d05 100644
+--- a/Annex/Perms.hs
++++ b/Annex/Perms.hs
+@@ -61,7 +61,7 @@ setAnnexPerm :: Bool -> RawFilePath -> Annex ()
+ setAnnexPerm = setAnnexPerm' Nothing
+ 
+ setAnnexPerm' :: Maybe ([FileMode] -> FileMode -> FileMode) -> Bool -> RawFilePath -> Annex ()
+-setAnnexPerm' modef isdir file = unlessM crippledFileSystem $
++setAnnexPerm' modef isdir file =
+ 	withShared $ liftIO . go
+   where
+ 	go GroupShared = void $ tryIO $ modifyFileMode file $ modef' $
+@@ -89,7 +89,7 @@ resetAnnexFilePerm = resetAnnexPerm False
+  - usual modes.
+  -}
+ resetAnnexPerm :: Bool -> RawFilePath -> Annex ()
+-resetAnnexPerm isdir file = unlessM crippledFileSystem $ do
++resetAnnexPerm isdir file = do
+ 	defmode <- liftIO defaultFileMode
+ 	let modef moremodes _oldmode = addModes moremodes defmode
+ 	setAnnexPerm' (Just modef) isdir file
+@@ -154,7 +154,7 @@ createWorkTreeDirectory dir = do
+  - that happens with write permissions.
+  -}
+ freezeContent :: RawFilePath -> Annex ()
+-freezeContent file = unlessM crippledFileSystem $
++freezeContent file =
+ 	withShared $ \sr -> freezeContent' sr file
+ 
+ freezeContent' :: SharedRepository -> RawFilePath -> Annex ()
+@@ -199,14 +199,12 @@ freezeContent'' sr file rv = do
+  - write permissions are ignored.
+  -}
+ checkContentWritePerm :: RawFilePath -> Annex (Maybe Bool)
+-checkContentWritePerm file = ifM crippledFileSystem
+-	( return (Just True)
+-	, do
++checkContentWritePerm file =
++	do
+ 		rv <- getVersion
+ 		hasfreezehook <- hasFreezeHook
+ 		withShared $ \sr -> liftIO $
+ 			checkContentWritePerm' sr file rv hasfreezehook
+-	)
+ 
+ checkContentWritePerm' :: SharedRepository -> RawFilePath -> Maybe RepoVersion -> Bool -> IO (Maybe Bool)
+ checkContentWritePerm' sr file rv hasfreezehook
+@@ -252,10 +250,8 @@ thawContent' sr file = do
+  - crippled filesystem, the file may be frozen, so try to thaw its
+  - permissions. -}
+ thawPerms :: Annex () -> Annex () -> Annex ()
+-thawPerms a hook = ifM crippledFileSystem
+-	( void (tryNonAsync a)
+-	, hook >> a
+-	)
++thawPerms a hook =
++	hook >> a
+ 
+ {- Blocks writing to the directory an annexed file is in, to prevent the
+  - file accidentally being deleted. However, if core.sharedRepository
+@@ -263,7 +259,7 @@ thawPerms a hook = ifM crippledFileSystem
+  - file.
+  -}
+ freezeContentDir :: RawFilePath -> Annex ()
+-freezeContentDir file = unlessM crippledFileSystem $ do
++freezeContentDir file = do
+ 	fastDebug "Annex.Perms" ("freezing content directory " ++ fromRawFilePath dir)
+ 	withShared go
+ 	freezeHook dir
+@@ -287,7 +283,7 @@ createContentDir dest = do
+ 	unlessM (liftIO $ R.doesPathExist dir) $
+ 		createAnnexDirectory dir 
+ 	-- might have already existed with restricted perms
+-	unlessM crippledFileSystem $ do
++	do
+ 		thawHook dir
+ 		liftIO $ allowWrite dir
+   where
+-- 
+2.30.2
+
+```
+
+This patch allows `git annex fix` on a crippled file system.
+
+```
+From 65fe6e362dfbf2f54c8da5ca17c59af26de5ff83 Mon Sep 17 00:00:00 2001
+From: Reiko Asakura <asakurareiko@protonmail.ch>
+Date: Sat, 23 Oct 2021 17:13:50 -0400
+Subject: [PATCH 1/2] Allow git-annex fix on crippled filesystem
+
+---
+ Command/Fix.hs | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Command/Fix.hs b/Command/Fix.hs
+index 39853c894..2d66c1461 100644
+--- a/Command/Fix.hs
++++ b/Command/Fix.hs
+@@ -31,7 +31,7 @@ cmd = noCommit $ withAnnexOptions [annexedMatchingOptions] $
+ 		paramPaths (withParams seek)
+ 
+ seek :: CmdParams -> CommandSeek
+-seek ps = unlessM crippledFileSystem $
++seek ps =
+ 	withFilesInGitAnnex ww seeker =<< workTreeItems ww ps
+   where
+ 	ww = WarnUnmatchLsFiles
+-- 
+2.30.2
+
+```
+
 ** Usage tips **
 
 * Symlinks are invalid in Windows if created before the target file exists, such as after `git annex add` or `git annex get`. This can be fixed by recreating them with any method, such as delete them and `git checkout`. Below is a sample script.

diff --git a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
index 3b257d7f7d..43f485ef2f 100644
--- a/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
+++ b/doc/tips/Using_git-annex_on_NTFS_with_WSL1.mdwn
@@ -1,32 +1,85 @@
-The following steps are tested on Windows 10 21h1 and are designed to avoid these two bugs:
+The following steps are tested on Windows 10 21h1 with Ubuntu 20 and are designed to allow use of the annexed files through both WSL and Windows.
 
-* [[bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol]]
-* [[bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem]]
+** Limitations **
+
+* The repository must be created with `annex.tune.objecthashlower=true`.
+* `git annex adjust --unlock` will not work. Unlocked files will work most of the time. Avoid `annex.addunlocked=true` because it is likely to not work.
 
 **Setup**
 
 * Enable Developer mode in Windows settings so that symlinks can be created without elevated privileges.
 * Mount the NTFS drive with metadata option. [`/etc/wsl.conf`](https://docs.microsoft.com/en-us/windows/wsl/wsl-config) can be used or a line such as `C: /mnt/c drvfs metadata` can be added in `/etc/fstab`.
-* Create an empty directory for the repo.
-    * With File Explorer go to Properties/Security/Advanced.
-        * Give "Authenticated Users" permission to [“Write attributes”, “Create files”, “Create folders” and “Delete subfolders and files”](https://devblogs.microsoft.com/commandline/improved-per-directory-case-sensitivity-support-in-wsl/) for this folder and subfolders.
-    * Enable case sensitivity with `setfattr -n system.wsl_case_sensitive -v 1 <path>`.
-        * This attribute will be inherited by new subdirectories but will not be automatically recursively applied to existing subdirectories.
-        * Set this attribute to 0 as appropriate if you do not have files that differ only by case, or if you have non-default git-annex [[tuning]].
-        * This attribute can be queried with `getfattr -n system.wsl_case_sensitive <path>`.
 * Initialize the repo.
-    * Set `git config annex.crippledfilesystem true` immediately after `git annex init` to avoid triggering the above two bugs.
-* Open Properties/Security/Advanced for .git/annex/objects.
-    * Deny "Authenticated Users" write permissions for files only and select "Replace all child object permission entries with inheritable permission entries from this object".
+    * If the repository is created by cloning, create local git-annex branch from the remote branch and remove the origin remote before `git annex init`.
+    * Set `git config annex.crippledfilesystem true` immediately after `git annex init`.
+    * Add the origin remote back if it was previously removed.
+* Safety of locked files will require these settings and scripts
+    * `git config annex.thawcontent-command 'wsl-thawcontent %path'`
+
+            #!/usr/bin/env bash
+
+            if [ -f "$1" ]; then
+                PERM='(DE,WD,AD)'
+            elif [ -d "$1" ]; then
+                PERM='(DE,DC,WD,AD)'
+            else
+                exit 0
+            fi
+
+            OUTPUT="$(icacls.exe "$(wslpath -w "$1")" /grant "Authenticated Users:$PERM")"
+
+            if [ "$?" -ne 0 ]; then
+                echo "$OUTPUT"
+                exit 1
+            fi
+
+    * `git config annex.freezecontent-command 'wsl-freezecontent %path'`
+
+            #!/usr/bin/env bash
+
+            if [ -f "$1" ]; then
+                if \[[ "$1" == *.git/annex/objects/* ]]; then
+                    PERM='(DE,WD,AD)'
+                else
+                    PERM='(WD,AD)'
+                fi
+            elif [ -d "$1" ]; then
+                PERM='(DE,DC,WD,AD)'
+            else
+                exit 0
+            fi
 
-** Setup with repo cloned from SSH **
+            OUTPUT="$(icacls.exe "$(wslpath -w "$1")" /deny "Authenticated Users:$PERM")"
 
-* If you encounter problems with older versions of git-annex.
-    * Create a local git-annex branch from the remote branch.
-    * Remove the origin remote.
-    * Do `git annex init` and other setup.
-    * Add back the origin remote.
+            if [ "$?" -ne 0 ]; then
+                echo "$OUTPUT"
+                exit 1
+            fi
 
-** Using symlinks and locked files **
+** Usage tips **
 
-* Symlinks might be broken and can be fixed by recreating them. You can also delete them and do a `git checkout`.
+* Symlinks are invalid in Windows if created before the target file exists, such as after `git annex add` or `git annex get`. This can be fixed by recreating them with any method, such as delete them and `git checkout`. Below is a sample script.
+
+		#!/usr/bin/env python3
+
+		import pathlib
+		import os
+
+		def do(p):
+			for c in list(p.iterdir()):
+				if c.is_symlink() and c.resolve().exists():
+					target = os.readlink(c) # use readlink here to get the relative link path
+					c.unlink()
+					c.symlink_to(target)
+				elif c.is_dir() and c.name != '.git':
+					do(c)
+
+		do(pathlib.Path('.'))
+
+* Sometimes there will SQLite errors using multiple jobs but retrying will work most of the time.
+
+** Related bugs **
+
+* [[bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol]]
+* [[bugs/WSL1__58___git-annex-add_fails_in_DrvFs_filesystem]]
+* [[bugs/problems_with_SSH_and_relative_paths]]

diff --git a/doc/bugs/git_commit_smudges_unncessarily.mdwn b/doc/bugs/git_commit_smudges_unncessarily.mdwn
index b0aae6b491..47f990de75 100644
--- a/doc/bugs/git_commit_smudges_unncessarily.mdwn
+++ b/doc/bugs/git_commit_smudges_unncessarily.mdwn
@@ -18,3 +18,5 @@ Through bisection, the problem was found to be introduced in [[!commit 428c91606
 ### 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)
 
 git-annex has worked wonderfully for managing my files across different machines and cloud storage services.
+
+[[done]]

diff --git a/doc/bugs/git_commit_smudges_unncessarily/comment_3_c30e84ae438810cbab70c401fd5125c0._comment b/doc/bugs/git_commit_smudges_unncessarily/comment_3_c30e84ae438810cbab70c401fd5125c0._comment
new file mode 100644
index 0000000000..3e03ba3035
--- /dev/null
+++ b/doc/bugs/git_commit_smudges_unncessarily/comment_3_c30e84ae438810cbab70c401fd5125c0._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="asakurareiko@f3d908c71c009580228b264f63f21c7274df7476"
+ nickname="asakurareiko"
+ avatar="http://cdn.libravatar.org/avatar/a865743e357add9d15081840179ce082"
+ subject="comment 3"
+ date="2022-09-24T19:43:47Z"
+ content="""
+This seems to be fixed now, maybe due to the changes made related to [[todo/git_status_smudges_unncessarily_after_unlock]].
+"""]]

diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn b/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
index 1c5c7f351c..bdf2701c24 100644
--- a/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
@@ -2,7 +2,7 @@
 attempting to the use feature which allows me to connect to a friends remote repository results in failure, in which i have tested using multiple methods
 
 ### What steps will reproduce the problem?
-#### webapp
+#### WEBAPP
 * open the webapp
 * add repository
 * choose "share with a friend"
@@ -26,10 +26,10 @@ attempting to the use feature which allows me to connect to a friends remote rep
 ### Please provide any additional information below.
 
 ### external dependency version info
-git annex: using git annex found in nixos repositories
-python version: attempted both python3 and python2.7
-magic-wormhole version: attempted both 0.12.0 under python3, and version 0.10.0 under python2.7
-tor version information: Tor version 0.4.7.10.
+* git annex: using git annex found in nixos repositories
+* python version: attempted both python3 and python2.7
+* magic-wormhole version: attempted both 0.12.0 under python3, and version 0.10.0 under python2.7
+* tor version information: Tor version 0.4.7.10.
 Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1q, Zlib 1.2.12, Liblzma 5.2.5, Libzstd 1.5.2 and Glibc 2.34 as libc.
 Tor compiled with GCC version 11.3.0
 
@@ -37,10 +37,9 @@ Tor compiled with GCC version 11.3.0
 ### transcript
 
 [[!format sh """
-# If you can, paste a complete transcript of the problem occurring here.
-# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
 
 #### WEBAPP
+##### error output after following steps as described above
 
 Failed to enable tor
 

diff --git a/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn b/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
new file mode 100644
index 0000000000..1c5c7f351c
--- /dev/null
+++ b/doc/bugs/git_annex_connecting_over_tor_does_not_work.mdwn
@@ -0,0 +1,81 @@
+### Please describe the problem.
+attempting to the use feature which allows me to connect to a friends remote repository results in failure, in which i have tested using multiple methods
+
+### What steps will reproduce the problem?
+#### webapp
+* open the webapp
+* add repository
+* choose "share with a friend"
+* click "lets get started"
+* encounter the error found in the transcript below
+
+
+#### COMMAND LINE
+##### enable tor
+* git annex enable tor
+* encounter error found in the transcript below
+
+##### p2p --pair
+* git annex p2p --pair
+* encounter the error found in the transcript
+
+### What version of git-annex are you using? On what operating system?
+
+
+
+### Please provide any additional information below.
+
+### external dependency version info
+git annex: using git annex found in nixos repositories
+python version: attempted both python3 and python2.7
+magic-wormhole version: attempted both 0.12.0 under python3, and version 0.10.0 under python2.7
+tor version information: Tor version 0.4.7.10.
+Tor is running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1q, Zlib 1.2.12, Liblzma 5.2.5, Libzstd 1.5.2 and Glibc 2.34 as libc.
+Tor compiled with GCC version 11.3.0
+
+
+### transcript
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+#### WEBAPP
+
+Failed to enable tor
+
+enable-tor 
+  You may be prompted for a password
+git-annex: This can only be run in a git-annex repository.
+
+git-annex: Failed to run as root: /nix/store/c42x83x25df9xd053xiii24mawnrlvrd-git-annex-10.20220504/bin/git-annex enable-tor 1000
+failed
+enable-tor: 1 failed
+
+#### COMMAND LINE
+##### enable tor
+git annex enable-tor
+Failed to enable tor
+
+enable-tor 
+  You may be prompted for a password
+git-annex: This can only be run in a git-annex repository.
+
+git-annex: Failed to run as root: /nix/store/c42x83x25df9xd053xiii24mawnrlvrd-git-annex-10.20220504/bin/git-annex enable-tor 1000
+failed
+enable-tor: 1 failed
+##### git annex p2p --pair
+git annex p2p --pair
+
+p2p pair peer1 (using Magic Wormhole) 
+
+  Failed sending data to pair.
+failed
+p2p: 1 failed
+
+# End of transcript or log.
+"""]]
+
+### 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)
+
+git annex has been awesome so far in helping track and backup my data, also for allowing me to output podcasts/audiobooks to a small mp3 player, as well as ebooks and pdfs to a kindle paper ewhite, which has made using my ereader no longer an inconvinient endeavour 

diff --git a/Annex/Link.hs b/Annex/Link.hs
index 496a071535..5329febcdb 100644
--- a/Annex/Link.hs
+++ b/Annex/Link.hs
@@ -316,7 +316,7 @@ unableToRestage mf = unwords
 	, "This is only a cosmetic problem affecting git status; git add,"
 	, "git commit, etc won't be affected."
 	, "To fix the git status display, you can run:"
-	, "git update-index -q --refresh " ++ fromMaybe "<file>" mf
+	, "git-annex restage"
 	]
 
 {- Parses a symlink target or a pointer file to a Key.
diff --git a/CHANGELOG b/CHANGELOG
index 172f0c14ec..1a9b38adb1 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -31,6 +31,7 @@ git-annex (10.20220823) UNRELEASED; urgency=medium
   * Improved handling of --time-limit when combined with -J
   * Fix updating git index file after getting an unlocked file 
     when annex.stalldetection is set.
+  * restage: New git-annex command, handles restaging unlocked files.
   * test: Added --test-with-git-config option.
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Aug 2022 15:03:04 -0400
diff --git a/CmdLine/GitAnnex.hs b/CmdLine/GitAnnex.hs
index 08c2bd832b..b845047cde 100644
--- a/CmdLine/GitAnnex.hs
+++ b/CmdLine/GitAnnex.hs
@@ -1,6 +1,6 @@
 {- git-annex main program
  -
- - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -114,6 +114,7 @@ import qualified Command.Proxy
 import qualified Command.DiffDriver
 import qualified Command.Smudge
 import qualified Command.FilterProcess
+import qualified Command.Restage
 import qualified Command.Undo
 import qualified Command.Version
 import qualified Command.RemoteDaemon
@@ -228,6 +229,7 @@ cmds testoptparser testrunner mkbenchmarkgenerator = map addGitAnnexCommonOption
 	, Command.DiffDriver.cmd
 	, Command.Smudge.cmd
 	, Command.FilterProcess.cmd
+	, Command.Restage.cmd
 	, Command.Undo.cmd
 	, Command.Version.cmd
 	, Command.RemoteDaemon.cmd
diff --git a/Command/Restage.hs b/Command/Restage.hs
new file mode 100644
index 0000000000..2f7f5ce6f2
--- /dev/null
+++ b/Command/Restage.hs
@@ -0,0 +1,25 @@
+{- git-annex command
+ -
+ - Copyright 2022 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU AGPL version 3 or higher.
+ -}
+
+module Command.Restage where
+
+import Command
+import qualified Annex
+import Annex.Link
+
+cmd :: Command
+cmd = command "restage" SectionPlumbing 
+	"estages unlocked files in the git index"
+	paramNothing (withParams seek)
+
+seek :: CmdParams -> CommandSeek
+seek = withNothing (commandAction start)
+
+start :: CommandStart
+start = starting "restage" (ActionItemOther Nothing) (SeekInput []) $ do
+	restagePointerFiles =<< Annex.gitRepo
+	next $ return True
diff --git a/Command/VCycle.hs b/Command/VCycle.hs
index c7f89a8563..5c8d84ba91 100644
--- a/Command/VCycle.hs
+++ b/Command/VCycle.hs
@@ -26,7 +26,7 @@ start ::CommandStart
 start = go =<< currentView
   where
 	go Nothing = giveup "Not in a view."
-	go (Just v) = starting "vcycle" (ActionItemOther Nothing) (SeekInput [])$ do
+	go (Just v) = starting "vcycle" (ActionItemOther Nothing) (SeekInput []) $ do
 		let v' = v { viewComponents = vcycle [] (viewComponents v) }
 		if v == v'
 			then do
diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn
index fc6f712b0d..8a3d282848 100644
--- a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn
@@ -91,4 +91,6 @@ I think I get it after I `annex move` and then `annex get` that file back. Just
 [[!meta author=yoh]]
 [[!tag projects/dandi]]
 
-> [[!meta title="annex.stalldetection prevents git-annex get from restaging unlocked files"]]
+[[!meta title="annex.stalldetection prevents git-annex get from restaging unlocked files"]]
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_16_4b8a360c38dfa4c8d22e3a96fbace0e5._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_16_4b8a360c38dfa4c8d22e3a96fbace0e5._comment
new file mode 100644
index 0000000000..018139bf8e
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_16_4b8a360c38dfa4c8d22e3a96fbace0e5._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""status update"""
+ date="2022-09-23T19:57:38Z"
+ content="""
+I've implemented the log file. The stalled transferrer case is now handled.
+This bug is fixed.
+
+As to a few other cases I considered in comments upthread:
+
+When a get/drop was interrupted before it could restage, 
+the next get/drop will cause the necessary restaging for the 
+interrupted process to happen. However, this doesn't help if there's
+nothing left to get/drop. Should git-annex always run restagePointerFiles
+on shutdown? That would make any git-annex command handle the restaging.
+But it doesn't seem right for query commands to do potentially a lot of
+work to handle this case. Anyway, I don't think this needs to be dealt
+with in this bug report.
+
+When multiple processes try to restage at the same time, one will
+restage everything that all of them logged. The others will still display a
+warning to the user that they couldn't restage. It would be hard to avoid
+displaying that warning, since it does need to warn when it was
+unable to restage because git has the index locked at the time. Anyway,
+I think it's ok to display the message despite the files having been
+restaged, because it's the same as a later git-annex process handling the
+restaging. (It does seem like two transferrers belonging to the same parent
+could collide in this way, and one display the warning, which isn't great..)
+
+I also implemented a "git-annex restage" command that
+is an easier way to restage in the cases where git-annex is not able
+to do it itself.
+"""]]
diff --git a/doc/git-annex-restage.mdwn b/doc/git-annex-restage.mdwn
new file mode 100644
index 0000000000..11d69142c3
--- /dev/null
+++ b/doc/git-annex-restage.mdwn
@@ -0,0 +1,34 @@
+# NAME
+
+git-annex restage - restages unlocked files in the git index
+
+# SYNOPSIS
+
+git annex restage
+
+# DESCRIPTION
+
+Since getting or dropping an unlocked file modifies the file in the work
+tree, git needs to be told that the modification does not change the
+content that it has recorded (the annex pointer). Restaging the file
+accomplishes that.
+
+You do not normally need to run this command, because usually git-annex
+is able to restage unlocked files itself. There are some situations
+where git-annex needs to restage a file, but the git index is locked,
+and so it cannot. It will then display a warning suggesting you run this
+command.
+
+It's safe to run this command even after you have made a modification to an
+unlocked file.
+
+# SEE ALSO
+
+[[git-annex]](1)
+[[git-annex-smudge]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index d95ec25f6b..7b4d3f3982 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -708,8 +708,8 @@ content from the key-value store.
 * `smudge`
 
   This command lets git-annex be used as a git filter driver, allowing
-  annexed files in the git repository to be unlocked at all times, instead
-  of being symlinks.
+  annexed files in the git repository to be unlocked regular files instead
+  of symlinks.

(Diff truncated)

diff --git a/doc/forum/HTTP_uploads/comment_2_d99641f1908073724f45dc3b170f3794._comment b/doc/forum/HTTP_uploads/comment_2_d99641f1908073724f45dc3b170f3794._comment
new file mode 100644
index 0000000000..f5eea1c57e
--- /dev/null
+++ b/doc/forum/HTTP_uploads/comment_2_d99641f1908073724f45dc3b170f3794._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 2"
+ date="2022-09-23T01:40:56Z"
+ content="""
+Thank you for the detailed response. That really clarifies things for me.
+
+I like the new error message! Much clearer.
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index e74887764c..172f0c14ec 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -31,6 +31,7 @@ git-annex (10.20220823) UNRELEASED; urgency=medium
   * Improved handling of --time-limit when combined with -J
   * Fix updating git index file after getting an unlocked file 
     when annex.stalldetection is set.
+  * test: Added --test-with-git-config option.
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Aug 2022 15:03:04 -0400
 
diff --git a/Test.hs b/Test.hs
index 5ec5d8d1de..78eeef882e 100644
--- a/Test.hs
+++ b/Test.hs
@@ -1,6 +1,6 @@
 {- git-annex test suite
  -
- - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ - Copyright 2010-2022 oey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -13,12 +13,12 @@ import Types.Test
 import Types.RepoVersion
 import Types.Concurrency
 import Test.Framework
-import Options.Applicative.Types
 
 import Test.Tasty
 import Test.Tasty.HUnit
 import Test.Tasty.QuickCheck
-import Options.Applicative (switch, long, short, help, internal, maybeReader, option)
+import Options.Applicative.Types
+import Options.Applicative (switch, long, short, help, internal, maybeReader, option, metavar)
 
 import qualified Data.Map as M
 import qualified Data.ByteString.Lazy.UTF8 as BU8
@@ -92,7 +92,7 @@ import qualified Utility.Gpg
 
 optParser :: Parser TestOptions
 optParser = TestOptions
-	<$> snd (tastyParser (tests 1 False True (TestOptions mempty False False Nothing mempty)))
+	<$> snd (tastyParser (tests 1 False True (TestOptions mempty False False Nothing mempty mempty)))
 	<*> switch
 		( long "keep-failures"
 		<> help "preserve repositories on test failure"
@@ -106,7 +106,19 @@ optParser = TestOptions
 		<> short 'J'
 		<> help "number of concurrent jobs"
 		))
+	<*> many (option (maybeReader parseconfigvalue)
+		( long "test-git-config"
+		<> help "run tests with a git config set"
+		<> metavar "NAME=VALUE"
+		))
 	<*> cmdParams "non-options are for internal use only"
+  where
+	parseconfigvalue s = case break (== '=') s of
+		(_, []) -> Nothing
+		(k, v) -> Just 
+			( Git.Types.ConfigKey (encodeBS k)
+			, Git.Types.ConfigValue (encodeBS (drop 1 v))
+			)
 
 runner :: TestOptions -> IO ()
 runner opts = parallelTestRunner opts tests
diff --git a/Test/Framework.hs b/Test/Framework.hs
index 2d8e0c6e2e..a4f24066ed 100644
--- a/Test/Framework.hs
+++ b/Test/Framework.hs
@@ -169,7 +169,7 @@ withtmpclonerepo' cfg a = do
 	case r of
 		Right () -> return ()
 		Left e -> do
-			whenM (keepFailures <$> getTestMode) $
+			whenM (keepFailuresOption . testOptions <$> getTestMode) $
 				putStrLn $ "** Preserving repo for failure analysis in " ++ clone
 			throwM e
 
@@ -255,6 +255,13 @@ configrepo dir = indir dir $ do
 	-- tell git-annex to not annex the ingitfile
 	git "config" ["annex.largefiles", "exclude=" ++ ingitfile]
 		"git config annex.largefiles"
+	-- set any additional git configs the user wants to test with
+	gc <- testGitConfig . testOptions <$> getTestMode
+	forM_ gc $ \case
+		(Git.Types.ConfigKey k, Git.Types.ConfigValue v) -> 
+			git "config" [decodeBS k, decodeBS v]
+				"git config from test options"
+		(Git.Types.ConfigKey _, Git.Types.NoConfigValue) -> noop
 
 ensuredir :: FilePath -> IO ()
 ensuredir d = do
@@ -483,15 +490,15 @@ data TestMode = TestMode
 	{ unlockedFiles :: Bool
 	, adjustedUnlockedBranch :: Bool
 	, annexVersion :: Types.RepoVersion.RepoVersion
-	, keepFailures :: Bool
-	} deriving (Show)
+	, testOptions :: TestOptions
+	}
 
 testMode :: TestOptions -> Types.RepoVersion.RepoVersion -> TestMode
 testMode opts v = TestMode
 	{ unlockedFiles = False
 	, adjustedUnlockedBranch = False
 	, annexVersion = v
-	, keepFailures = keepFailuresOption opts
+	, testOptions = opts
 	}
 
 hasUnlockedFiles :: TestMode -> Bool
diff --git a/Types/Test.hs b/Types/Test.hs
index b41864d256..9d0af77208 100644
--- a/Types/Test.hs
+++ b/Types/Test.hs
@@ -11,12 +11,14 @@ import Test.Tasty.Options
 
 import Types.Concurrency
 import Types.Command
+import Git.Types
 
 data TestOptions = TestOptions
 	{ tastyOptionSet :: OptionSet
 	, keepFailuresOption :: Bool
 	, fakeSsh :: Bool
 	, concurrentJobs :: Maybe Concurrency
+	, testGitConfig :: [(ConfigKey, ConfigValue)]
 	, internalData :: CmdParams
 	}
 
diff --git a/doc/git-annex-test.mdwn b/doc/git-annex-test.mdwn
index 31c77b0cb2..17923cc026 100644
--- a/doc/git-annex-test.mdwn
+++ b/doc/git-annex-test.mdwn
@@ -30,6 +30,20 @@ framework. Pass --help for details about those.
   When there are test failures, leave the `.t` directory populated with
   repositories that demonstate the failures, for later analysis.
 
+* `--test-git-config name=value`
+
+  The test suite prevents git from reading any git configuration files.
+  Usually it is a good idea to run the test suite with a standard 
+  git configuration. However, this option can be useful to see what
+  effect a git configuration setting has on the test suite. 
+
+  Some configuration settings will break the test suite, in ways that are
+  due to a bug in git-annex. But it is possible that changing a
+  configuration can find a legitimate bug in git-annex.
+
+  One valid use of this is to change a git configuration to a value that
+  is planned to be the new default in a future version of git.
+
 # SEE ALSO
 
 [[git-annex]](1)
diff --git a/doc/todo/specify_gitconfig_for_test_suite.mdwn b/doc/todo/specify_gitconfig_for_test_suite.mdwn
index 891fb9c66e..78cf7d78f5 100644
--- a/doc/todo/specify_gitconfig_for_test_suite.mdwn
+++ b/doc/todo/specify_gitconfig_for_test_suite.mdwn
@@ -1,5 +1,8 @@
 `git-annex test` prevents ~/.gitconfig or /etc/gitconfig from being read.
+The `-c` option also doesn't propagate into the test suite. 
 
 It would sometimes be useful to test git-annex with a given git config set.
 Although some might break the test suite, others might expose actual bugs
 in git-annex. --[[Joey]]
+
+> Added "--test-git-config" option, [[done]] --[[Joey]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_15_df08c2530b890544d5eb2df792c8fd4b._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_15_df08c2530b890544d5eb2df792c8fd4b._comment
new file mode 100644
index 0000000000..5f5c21ab67
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_15_df08c2530b890544d5eb2df792c8fd4b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2022-09-22T18:42:06Z"
+ content="""
+@yarikoptic oh, `git-annex test` does prevent global gitconfig from
+influeencing the tests. So your matrix test won't work if you're
+running `git-annex test` in it. If you're running other git-annex commands
+in datalad's test suite, it would work though.
+
+I've opened [[todo/specify_gitconfig_for_test_suite]].
+"""]]
diff --git a/doc/todo/specify_gitconfig_for_test_suite.mdwn b/doc/todo/specify_gitconfig_for_test_suite.mdwn
new file mode 100644
index 0000000000..891fb9c66e
--- /dev/null
+++ b/doc/todo/specify_gitconfig_for_test_suite.mdwn
@@ -0,0 +1,5 @@
+`git-annex test` prevents ~/.gitconfig or /etc/gitconfig from being read.
+
+It would sometimes be useful to test git-annex with a given git config set.
+Although some might break the test suite, others might expose actual bugs
+in git-annex. --[[Joey]]

diff --git a/Annex/TransferrerPool.hs b/Annex/TransferrerPool.hs
index 513dc1f28e..b1046a9590 100644
--- a/Annex/TransferrerPool.hs
+++ b/Annex/TransferrerPool.hs
@@ -217,9 +217,15 @@ mkTransferrer signalactonsvar (RunTransferrer program params batchmaker) = do
 		, transferrerWrite = writeh
 		, transferrerHandle = ph
 		, transferrerShutdown = do
-			hClose readh
+			-- The transferrer may write to stdout
+			-- as it's shutting down, so don't close
+			-- the readh right away. Instead, drain
+			-- anything sent to it.
+			drainer <- async $ void $ hGetContents readh
 			hClose writeh
 			void $ waitForProcess ph
+			wait drainer
+			hClose readh
 			unregistersignalprop
 		}
 
diff --git a/CHANGELOG b/CHANGELOG
index eebd73c927..e74887764c 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -29,6 +29,8 @@ git-annex (10.20220823) UNRELEASED; urgency=medium
     directory to somewhere else.
     (Introduced in version 10.20220525)
   * Improved handling of --time-limit when combined with -J
+  * Fix updating git index file after getting an unlocked file 
+    when annex.stalldetection is set.
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Aug 2022 15:03:04 -0400
 
diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_13_5c03731700b2a025755fb06c9a96f331._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_13_5c03731700b2a025755fb06c9a96f331._comment
new file mode 100644
index 0000000000..7574901278
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_13_5c03731700b2a025755fb06c9a96f331._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 13"""
+ date="2022-09-22T18:16:22Z"
+ content="""
+Avoided the early stdout handle close, and that did fix this bug as
+reported.
+
+The related problems I identified in comment #12 are still unfixed, so
+leaving this open for now.
+
+I think what ought to be done to wrap this up is make restagePointerFile
+record the files that need to be restaged in a log file. Then at shutdown,
+git-annex can read the log file, and restage everything listed in it.
+This will solve multiple problems:
+
+* When a previous git-annex process was interrupted after a get/drop of an
+  unlocked file, the file will be in the log, so git-annex can notice
+  that and handle the restaging.
+* When a stalled `git-annex transferrer` is killed, the parent git-annex
+  will read the log and handle the restaging that it was not able to do.
+* When multiple processes are trying to restage files at the same time,
+  an exclusive lock can be used to make only one of them run, and it can
+  handle restaging the files that the others have recorded in the log too.
+* As a bonus, in the situations where git-annex is legitimately unable to
+  restage files, it can still record them to be restaged later. And the
+  "only a cosmetic problem" message can tell the user to run a single
+  simple git-annex command, rather than a complicated 
+  `git update-index` command per file.
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_12_5cdddca4ca03216b68d443eeb49af581._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_12_5cdddca4ca03216b68d443eeb49af581._comment
new file mode 100644
index 0000000000..6d8bfbcc4e
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_12_5cdddca4ca03216b68d443eeb49af581._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 12"
+ date="2022-09-22T18:14:15Z"
+ content="""
+Adding a matrix run where I initiated a custom config settings to our [datalad/git-annex](https://github.com/datalad/git-annex/pull/133) CI run.  Let's see how that goes.  May be some other interesting config settings to add there? e.g. retries etc?  or global `~/.gitconfig` is not used/mocked away during tests? (e.g. we do that in datalad, so I had to trick that in [PR against datalad](https://github.com/datalad/datalad/pull/7056) to test against this setting being set)
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_12_68a79183b04b99d4b00b363e3cbe3f3c._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_12_68a79183b04b99d4b00b363e3cbe3f3c._comment
new file mode 100644
index 0000000000..f8955e7b05
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_12_68a79183b04b99d4b00b363e3cbe3f3c._comment
@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 12"""
+ date="2022-09-22T17:40:57Z"
+ content="""
+So, `git-annex transferrer`, after downloading the content, does handle
+populating pointer files. So it calls restagePointerFile to register a cleanup
+action.
+
+Whatever is making that process exit 1 must be preventing the cleanup
+action from being run. And I think what that is, is that its stdout handle
+gets closed at the same time its stdin handle is closed. I tried running
+`git-annex transferrer` manually and feeding it a transfer request on
+stdin. After its stdin was closed, it proceeded to send 
+`"om (recording state in git...)\n"` to stdout, and that would fail
+with stdout already closed.
+
+Worse, I suspect there's another problem.. When a stall actually
+is detected, git-annex kills the `git-annex transferrer` process that has
+stalled. But suppose that process has already successfully downloaded some
+content and populated pointer files. Killing it would prevent it from
+running restagePointerFile on those. It seems that to solve this,
+it would need to communicate back to the parent what pointer files need to
+be restaged. (Which would also solve the exit 1 problem, although not
+necessarily in the best way.)
+
+Also, I think that multiple processes running the restagePointerFile
+cleanup action at the same time can be a problem, because one will
+lock the index and the rest will fail to restage. Not what's happening
+here, but with -J, there would be multiple `git-annex transferrer`
+processes doing that at the same time at the end.
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_11_f8a54670d8eaf00624e9b8f85e803864._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_11_f8a54670d8eaf00624e9b8f85e803864._comment
new file mode 100644
index 0000000000..ea0faa1353
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_11_f8a54670d8eaf00624e9b8f85e803864._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2022-09-22T17:38:45Z"
+ content="""
+Yeah, a whole git-annex test run with stalldetection set would have found
+this bug. Which seems a bit heavy-weight for the test suite to try as a
+separate pass by default. But then again, stalldetection does significantly
+change how git-annex operates since it has to fork off child processes that
+it can kill when they stall.
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment
index 6e05545118..c7378771ce 100644
--- a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment
@@ -3,12 +3,10 @@
  subject="""comment 9"""
  date="2022-09-22T17:04:35Z"
  content="""
-Thanks for the --debug. It shows that git-annex is asking git to refresh the index,
-although from this we can't see for sure if it fed the name of the file in on stdin or not:
+Thanks for the --debug. It shows that git-annex is not running 
+`git update-index --refresh` at all.
 
-	[2022-09-21 21:30:03.77319] (Utility.Process) process [3968453] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"update-index\",\"-z\",\"--index-info\"]
-
-The other thing that seems maybe relevant is that the transfer happens in a `git-annex transferrer` process.
+And it shows that the transfer happens in a `git-annex transferrer` process.
 So, I think you have annex.stalldetection set.
 
 	[2022-09-21 21:29:59.931525] (Utility.Process) process [3968203] chat: /home/dandi/miniconda3/envs/dandisets/bin/git-annex [\"transferrer\",\"-c\",\"annex.debug=true\"]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_10_43f1eec4aa317ff3b1a4fc18def96c6f._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_10_43f1eec4aa317ff3b1a4fc18def96c6f._comment
new file mode 100644
index 0000000000..4941e433c2
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_10_43f1eec4aa317ff3b1a4fc18def96c6f._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 10"
+ date="2022-09-22T17:34:35Z"
+ content="""
+damn, I should have shared my config!  I also do have `annex.stalldetection` set!
+
+```
+[annex]
+	stalldetection = 1KB/120s
+```
+
+never thought it might be related.  We should look into having some matrix test run with such config set.
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn
index ee7f06bf72..fc6f712b0d 100644
--- a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn
@@ -90,3 +90,5 @@ I think I get it after I `annex move` and then `annex get` that file back. Just
 
 [[!meta author=yoh]]
 [[!tag projects/dandi]]
+
+> [[!meta title="annex.stalldetection prevents git-annex get from restaging unlocked files"]]
diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_8_927028d040b0e24d772b667324b1a5e1._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_8_927028d040b0e24d772b667324b1a5e1._comment
new file mode 100644
index 0000000000..422fc09ad2
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_8_927028d040b0e24d772b667324b1a5e1._comment
@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 8"""
+ date="2022-09-22T17:02:04Z"
+ content="""
+I've fixed the issue I found with --timestamp combined with -J. Which I do
+think could have resulted in the same kind of problem. But you've shown
+that is not the cause in your case..
+"""]]
diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment
new file mode 100644
index 0000000000..6e05545118
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_9_64ba2901154b629a9697b427f3ad92e2._comment
@@ -0,0 +1,21 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 9"""
+ date="2022-09-22T17:04:35Z"
+ content="""
+Thanks for the --debug. It shows that git-annex is asking git to refresh the index,
+although from this we can't see for sure if it fed the name of the file in on stdin or not:
+
+	[2022-09-21 21:30:03.77319] (Utility.Process) process [3968453] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"update-index\",\"-z\",\"--index-info\"]
+
+The other thing that seems maybe relevant is that the transfer happens in a `git-annex transferrer` process.
+So, I think you have annex.stalldetection set.
+
+	[2022-09-21 21:29:59.931525] (Utility.Process) process [3968203] chat: /home/dandi/miniconda3/envs/dandisets/bin/git-annex [\"transferrer\",\"-c\",\"annex.debug=true\"]
+
+And interestingly, that transferrer process fails at the end:
+
+	[2022-09-21 21:30:06.373343] (Utility.Process) process [3968203] done ExitFailure 1
+
+Aha! I can reproduce it by setting annex.stalldetection.
+"""]]

diff --git a/Annex.hs b/Annex.hs
index 6e4ebb9b70..0f0464dcac 100644
--- a/Annex.hs
+++ b/Annex.hs
@@ -200,7 +200,7 @@ data AnnexState = AnnexState
 	, cleanupactions :: M.Map CleanupAction (Annex ())
 	, sentinalstatus :: Maybe SentinalStatus
 	, errcounter :: Integer
-	, skippedfiles :: Bool
+	, reachedlimit :: Bool
 	, adjustedbranchrefreshcounter :: Integer
 	, unusedkeys :: Maybe (S.Set Key)
 	, tempurls :: M.Map Key URLString
@@ -253,7 +253,7 @@ newAnnexState c r = do
 		, cleanupactions = M.empty
 		, sentinalstatus = Nothing
 		, errcounter = 0
-		, skippedfiles = False
+		, reachedlimit = False
 		, adjustedbranchrefreshcounter = 0
 		, unusedkeys = Nothing
 		, tempurls = M.empty
diff --git a/CHANGELOG b/CHANGELOG
index 0623c8b6e7..eebd73c927 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -28,6 +28,7 @@ git-annex (10.20220823) UNRELEASED; urgency=medium
     repository when --git-dir or GIT_DIR is specified to relocate the git
     directory to somewhere else.
     (Introduced in version 10.20220525)
+  * Improved handling of --time-limit when combined with -J
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Aug 2022 15:03:04 -0400
 
diff --git a/CmdLine/Action.hs b/CmdLine/Action.hs
index 6d7932bb0b..d99cdad17a 100644
--- a/CmdLine/Action.hs
+++ b/CmdLine/Action.hs
@@ -32,8 +32,8 @@ import qualified System.Console.Regions as Regions
 {- Runs a command, starting with the check stage, and then
  - the seek stage. Finishes by running the continuation.
  -
- - Can exit when there was a problem or when files were skipped.
- - Also shows a count of any failures when that is enabled.
+ - Can exit when there was a problem or when a time or size limit was
+ - reached. Also shows a count of any failures when that is enabled.
  -}
 performCommandAction :: Bool -> Command -> CommandSeek -> Annex () -> Annex ()
 performCommandAction canexit (Command { cmdcheck = c, cmdname = name }) seek cont = do
@@ -43,19 +43,19 @@ performCommandAction canexit (Command { cmdcheck = c, cmdname = name }) seek con
 	finishCommandActions
 	cont
 	st <- Annex.getState id
-	when canexit $ liftIO $ case (Annex.errcounter st, Annex.skippedfiles st) of
+	when canexit $ liftIO $ case (Annex.errcounter st, Annex.reachedlimit st) of
 		(0, False) -> noop
 		(errcnt, False) -> do
 			showerrcount errcnt
 			exitWith $ ExitFailure 1
-		(0, True) -> exitskipped
+		(0, True) -> exitreachedlimit
 		(errcnt, True) -> do
 			showerrcount errcnt
-			exitskipped
+			exitreachedlimit
   where
 	showerrcount cnt = hPutStrLn stderr $
 		name ++ ": " ++ show cnt ++ " failed"
-	exitskipped = exitWith $ ExitFailure 101
+	exitreachedlimit = exitWith $ ExitFailure 101
 
 commandActions :: [CommandStart] -> Annex ()
 commandActions = mapM_ commandAction
@@ -328,7 +328,7 @@ checkSizeLimit (Just sizelimitvar) startmsg a =
 			Nothing -> do
 				fsz <- catchMaybeIO $ withObjectLoc k $
 					liftIO . getFileSize
-				maybe skipped go fsz
+				maybe reachedlimit go fsz
 		Nothing -> a
   where
 	go sz = do
@@ -342,6 +342,6 @@ checkSizeLimit (Just sizelimitvar) startmsg a =
 				else return False
 		if fits 
 			then a
-			else skipped
+			else reachedlimit
 	
-	skipped = Annex.changeState $ \s -> s { Annex.skippedfiles = True }
+	reachedlimit = Annex.changeState $ \s -> s { Annex.reachedlimit = True }
diff --git a/CmdLine/Seek.hs b/CmdLine/Seek.hs
index 24ee8f03f4..895250ec8d 100644
--- a/CmdLine/Seek.hs
+++ b/CmdLine/Seek.hs
@@ -4,7 +4,7 @@
  - the values a user passes to a command, and prepare actions operating
  - on them.
  -
- - Copyright 2010-2021 Joey Hess <id@joeyh.name>
+ - Copyright 2010-2022 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -41,7 +41,6 @@ import Annex.Link
 import Annex.InodeSentinal
 import Annex.Concurrent
 import Annex.CheckIgnore
-import Annex.Action
 import qualified Annex.Branch
 import qualified Database.Keys
 import qualified Utility.RawFilePath as R
@@ -49,6 +48,7 @@ import Utility.Tuple
 import Utility.HumanTime
 
 import Control.Concurrent.Async
+import Control.Concurrent.STM
 import System.Posix.Types
 import Data.IORef
 import Data.Time.Clock.POSIX
@@ -610,20 +610,25 @@ notSymlink :: RawFilePath -> IO Bool
 notSymlink f = liftIO $ not . isSymbolicLink <$> R.getSymbolicLinkStatus f
 
 {- Returns an action that, when there's a time limit, can be used
- - to check it before processing a file. The first action is run when over the
- - time limit, otherwise the second action is run. -}
+ - to check it before processing a file. The first action is run when
+ - over the time limit, otherwise the second action is run one time to
+ - clean up. -}
 mkCheckTimeLimit :: Annex (Annex () -> Annex () -> Annex ())
 mkCheckTimeLimit = Annex.getState Annex.timelimit >>= \case
 	Nothing -> return $ \_ a -> a
-	Just (duration, cutoff) -> return $ \cleanup a -> do
-		now <- liftIO getPOSIXTime
-		if now > cutoff
-			then do
-				warning $ "Time limit (" ++ fromDuration duration ++ ") reached! Shutting down..."
-				shutdown True
-				cleanup
-				liftIO $ exitWith $ ExitFailure 101
-			else a
+	Just (duration, cutoff) -> do
+		warningshownv <- liftIO $ newTVarIO False
+		return $ \cleanup a -> do
+			now <- liftIO getPOSIXTime
+			if now > cutoff
+				then do
+					warningshown <- liftIO $ atomically $
+						swapTVar warningshownv True
+					unless warningshown $ do
+						Annex.changeState $ \s -> s { Annex.reachedlimit = True }
+						warning $ "Time limit (" ++ fromDuration duration ++ ") reached! Shutting down..."
+						cleanup
+				else a
 
 propagateLsFilesError :: IO Bool -> Annex ()
 propagateLsFilesError cleanup =
diff --git a/doc/git-annex-common-options.mdwn b/doc/git-annex-common-options.mdwn
index 0705496035..932d7288c1 100644
--- a/doc/git-annex-common-options.mdwn
+++ b/doc/git-annex-common-options.mdwn
@@ -68,8 +68,10 @@ Most of these options are accepted by all git-annex commands.
   Limits how long a git-annex command runs. The time can be something
   like "5h", or "30m" or even "45s" or "10d".
 
-  Note that git-annex may continue running a little past the specified
-  time limit, in order to finish processing a file.
+  Note that git-annex may continue running for some time past the specified
+  time limit, in order to finish processing files it started before the
+  time limit was reached. That and a cleaner shutdown are the differences
+  between using this option and a command like `timeout(1)`.
 
   When the time limit prevents git-annex from doing all it
   was asked to, it will exit with a special code, 101.

diff --git a/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_2_0c101e5b017f56897599c2cbd37b1754._comment b/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_2_0c101e5b017f56897599c2cbd37b1754._comment
new file mode 100644
index 0000000000..6f25880923
--- /dev/null
+++ b/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_2_0c101e5b017f56897599c2cbd37b1754._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 2"
+ date="2022-09-22T06:24:04Z"
+ content="""
+Thank you joey, you're awesome! 👍
+"""]]

diff --git a/doc/git-annex-preferred-content/comment_6_ef4fad67d2e2c5044c8134e426c3d086._comment b/doc/git-annex-preferred-content/comment_6_ef4fad67d2e2c5044c8134e426c3d086._comment
deleted file mode 100644
index fa9a0aa00f..0000000000
--- a/doc/git-annex-preferred-content/comment_6_ef4fad67d2e2c5044c8134e426c3d086._comment
+++ /dev/null
@@ -1,13 +0,0 @@
-[[!comment format=mdwn
- username="rinomizu5@5ead4c82685c65d7717dbd5591b80425036ae9e3"
- nickname="rinomizu5"
- avatar="http://cdn.libravatar.org/avatar/62478823018c68821064febcda7e5d4f"
- subject=""not inbackend=URL" is failed with parse error"
- date="2022-09-21T07:04:55Z"
- content="""
-I tried the `git annex wanted gin \"not inbackend=URL\"` because I don't want to sync to gin remote if the backend key is a URL. But it failed with a Parse error.  
-The syntax says `inbackend=name`, but is `URL` not included in this `name`?  
-Please advise me what to do.  
-
-
-"""]]

diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_8_37eb9d35191bcfc0e7e4496f5720cbed._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_8_37eb9d35191bcfc0e7e4496f5720cbed._comment
new file mode 100644
index 0000000000..e80c02e061
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_8_37eb9d35191bcfc0e7e4496f5720cbed._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="jgoerzen"
+ avatar="http://cdn.libravatar.org/avatar/090740822c9dcdb39ffe506b890981b4"
+ subject="comment 8"
+ date="2022-09-22T03:40:04Z"
+ content="""
+Thank you!
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_7_3186ec45f20c4d768c7682e1d42fa24c._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_7_3186ec45f20c4d768c7682e1d42fa24c._comment
new file mode 100644
index 0000000000..419f0415bc
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_7_3186ec45f20c4d768c7682e1d42fa24c._comment
@@ -0,0 +1,58 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 7"
+ date="2022-09-22T01:33:24Z"
+ content="""
+sorry I have not mentioned your [earlier comment 4](http://git-annex.branchable.com/bugs/reports_file___34__modified__34___whenever_it_is_not/#comment-ca0281ff580c91c40e429fbbb71a3791) but my clarification above I think gives the answers to your questions ;)
+
+<details>
+<summary>FWIW here is the get --debug output </summary> 
+
+```shell
+[2022-09-21 21:29:59.904218] (Utility.Process) process [3968193] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"ls-files\",\"--stage\",\"-z\",\"--error-unmatch\",\"--\",\".dandi/assets.json\"]
+[2022-09-21 21:29:59.904725] (Utility.Process) process [3968194] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch-check=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+[2022-09-21 21:29:59.905645] (Utility.Process) process [3968195] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+[2022-09-21 21:29:59.906012] (Utility.Process) process [3968196] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"git-annex\"]
+[2022-09-21 21:29:59.907578] (Utility.Process) process [3968196] done ExitSuccess
+[2022-09-21 21:29:59.907891] (Utility.Process) process [3968197] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2022-09-21 21:29:59.913611] (Utility.Process) process [3968197] done ExitSuccess
+[2022-09-21 21:29:59.914676] (Utility.Process) process [3968198] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log\",\"refs/heads/git-annex..5f5efa8544ff02c9261dd1590425dcea37a55526\",\"--pretty=%H\",\"-n1\"]
+[2022-09-21 21:29:59.916707] (Utility.Process) process [3968198] done ExitSuccess
+[2022-09-21 21:29:59.916968] (Utility.Process) process [3968199] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"log\",\"refs/heads/git-annex..18497e6e9cab7754a85256416c361fee36ba65b2\",\"--pretty=%H\",\"-n1\"]
+[2022-09-21 21:29:59.918722] (Utility.Process) process [3968199] done ExitSuccess
+[2022-09-21 21:29:59.919069] (Utility.Process) process [3968200] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch=%(objectname) %(objecttype) %(objectsize)\",\"--buffer\"]
+get .dandi/assets.json [2022-09-21 21:29:59.921463] (Utility.Process) process [3968202] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"cat-file\",\"--batch\"]
+(from dandi-dandisets-dropbox...) [2022-09-21 21:29:59.931525] (Utility.Process) process [3968203] chat: /home/dandi/miniconda3/envs/dandisets/bin/git-annex [\"transferrer\",\"-c\",\"annex.debug=true\"]
+[2022-09-21 21:29:59.93162] (Annex.TransferrerPool) > d rdandi-dandisets-dropbox SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json .dandi/assets.json
+[2022-09-21 21:29:59.942599] (Annex.TransferrerPool) < opb
+
+[2022-09-21 21:29:59.942718] (Annex.TransferrerPool) < ops 69507227
+[2022-09-21 21:30:03.103409] (Annex.TransferrerPool) < ope
+[2022-09-21 21:30:03.103539] (Annex.TransferrerPool) < om (checksum...) 
+(checksum...) [2022-09-21 21:30:03.768599] (Annex.TransferrerPool) < t
+[2022-09-21 21:30:03.768843] (Annex.Branch) read 6e0/a70/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json.log
+[2022-09-21 21:30:03.770259] (Annex.Branch) set 6e0/a70/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json.log
+ok
+[2022-09-21 21:30:03.770361] (Utility.Process) process [3968200] done ExitSuccess
+[2022-09-21 21:30:03.770425] (Utility.Process) process [3968195] done ExitSuccess
+[2022-09-21 21:30:03.770484] (Utility.Process) process [3968194] done ExitSuccess
+[2022-09-21 21:30:03.770531] (Utility.Process) process [3968193] done ExitSuccess
+[2022-09-21 21:30:03.771187] (Utility.Process) process [3968452] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"hash-object\",\"-w\",\"--stdin-paths\",\"--no-filters\"]
+[2022-09-21 21:30:03.77319] (Utility.Process) process [3968453] feed: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"update-index\",\"-z\",\"--index-info\"]
+[2022-09-21 21:30:04.063182] (Utility.Process) process [3968453] done ExitSuccess
+[2022-09-21 21:30:04.063779] (Utility.Process) process [3968463] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]
+[2022-09-21 21:30:04.065352] (Utility.Process) process [3968463] done ExitSuccess
+(recording state in git...)
+[2022-09-21 21:30:04.06587] (Utility.Process) process [3968464] read: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"write-tree\"]
+[2022-09-21 21:30:04.407935] (Utility.Process) process [3968464] done ExitSuccess
+[2022-09-21 21:30:04.408528] (Utility.Process) process [3968468] chat: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"commit-tree\",\"56c62dcc21145201f9454a2dd6e75cc37f072ee4\",\"--no-gpg-sign\",\"-p\",\"refs/heads/git-annex\"]
+[2022-09-21 21:30:04.410591] (Utility.Process) process [3968468] done ExitSuccess
+[2022-09-21 21:30:04.413623] (Utility.Process) process [3968469] call: git [\"--git-dir=.git\",\"--work-tree=.\",\"--literal-pathspecs\",\"-c\",\"annex.debug=true\",\"update-ref\",\"refs/heads/git-annex\",\"c3a1f9208649b47621b1424b055bd9871aa2fc79\"]
+[2022-09-21 21:30:04.415318] (Utility.Process) process [3968469] done ExitSuccess
+[2022-09-21 21:30:04.416301] (Utility.Process) process [3968202] done ExitSuccess
+[2022-09-21 21:30:04.416574] (Utility.Process) process [3968452] done ExitSuccess
+[2022-09-21 21:30:06.373343] (Utility.Process) process [3968203] done ExitFailure 1
+```
+</details>
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_6_48819ddcb8713087c78db8941e4c1151._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_6_48819ddcb8713087c78db8941e4c1151._comment
new file mode 100644
index 0000000000..a3f60308dc
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_6_48819ddcb8713087c78db8941e4c1151._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2022-09-22T01:03:18Z"
+ content="""
+may be it one of those options, in my case - it is just a straight `get` on that single unlocked file:
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+nothing to commit, working tree clean
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ cat .dandi/assets.json
+/annex/objects/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git annex get .dandi/assets.json
+get .dandi/assets.json (from dandi-dandisets-dropbox...)
+(checksum...) ok
+(recording state in git...)
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+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:   .dandi/assets.json
+
+no changes added to commit (use \"git add\" and/or \"git commit -a\")
+
+```
+"""]]

diff --git a/doc/forum/Not_enough_free_space/comment_7_7cf8cf6d15324b840336be561423d34b._comment b/doc/forum/Not_enough_free_space/comment_7_7cf8cf6d15324b840336be561423d34b._comment
new file mode 100644
index 0000000000..f6a4803103
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_7_7cf8cf6d15324b840336be561423d34b._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="comment 7"
+ date="2022-09-21T22:30:20Z"
+ content="""
+Greeting, joey. I have not. I am waiting for some quiet free time in which I am well rested, to reduce the possibility of messing things up more. :-)
+
+In the meantime, I am seeing, in my `.git/config`:
+
+```
+[core]
+	repositoryformatversion = 0
+	filemode = true
+	bare = false
+	logallrefupdates = true
+        diskreserve = 1000MB
+```
+
+I think that reserve is for _git_, not _git-annex_. I may as well start setting that variable. I am using git-annex, in part, because I need to have my stuff spread across multiple media.
+
+Looking at your example output, I am getting a less helpful result. Possibly due to what you explain. However I am concerned with the possibility of your \"to do\" is being too specific. Detecting free disk space is not easy (I also use BTRFS, so I know that!). Maybe transferring / growing more than X GB it would print a warning (that would not interfere with automatic usage)? Or easily rollback that last incomplete file to ensure the metadata and other files write cleanly. Certainly you know better than me what works and what is needed.
+
+By the way, if anyone would be interested in writing a book on git-annex, with all these nice tips, I would buy a copy! (I am also willing to provide feedback for a WIP)
+
+Finally, I would also like to add that, looking once more at the log I can see the file mode change, as you said. I now have confirmation that the suspected _sync_ caused this problem.
+
+Thank you once again for all your help.
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_5_7d339e9a04a7c303949523b235a046ec._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_5_7d339e9a04a7c303949523b235a046ec._comment
new file mode 100644
index 0000000000..d0fc8a0a57
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_5_7d339e9a04a7c303949523b235a046ec._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 5"""
+ date="2022-09-21T22:06:49Z"
+ content="""
+Seems likely that the --time-limit option, when combined with -J,
+could result in git-annex exiting before a worker thread gets a chance to
+call stagePointerFile. I have not verified this, and it would be unlikely
+to result in the same file being affected reproducibly.
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment
index d4cfce6fbc..30e9d721ac 100644
--- a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment
@@ -13,9 +13,9 @@ I expect that running `git update-index --refresh .dandi/assets.json`
 will fix git status. Can you confirm?
 
 The only way I know of that this can happen without the message is if a
-drop or a get is still running, or gets interrupted after it
-gets an unlocked file, but before it finishes. One of the last things
-git-annex does is restage the unlocked files.
+drop or a get is still running, or gets interrupted. One of the last things
+git-annex before exiting is restage all the unlocked files that it has
+updated.
 
 Short of that, it seems like it would have to be a bug that prevents
 restagePointerFile from working. Which might not be a bug in git-annex,

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment
new file mode 100644
index 0000000000..d4cfce6fbc
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_4_ac9c166c2b0c3aad8391abb56654ecf2._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-09-21T19:19:08Z"
+ content="""
+So you can reproduce this? I am pretty sure it's not as simple as a drop
+followed by a get, so more information about reproducing it seems crucial.
+
+I assume you are *not* seeing the "This is only a cosmetic problem affecting git status"
+message?
+
+I expect that running `git update-index --refresh .dandi/assets.json`  
+will fix git status. Can you confirm?
+
+The only way I know of that this can happen without the message is if a
+drop or a get is still running, or gets interrupted after it
+gets an unlocked file, but before it finishes. One of the last things
+git-annex does is restage the unlocked files.
+
+Short of that, it seems like it would have to be a bug that prevents
+restagePointerFile from working. Which might not be a bug in git-annex,
+if the problem involves git's handling of timestamps in the index, for
+example. (Which is known to have some odd behaviors.)
+
+(git-annex could be improved to do the
+restaging later when interrupted and possibly after such a bug.
+But there's no way to make it recover in `git status`, because
+git doesn't run it in this situation.)
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index 6a7342c639..0623c8b6e7 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,5 +1,6 @@
 git-annex (10.20220823) UNRELEASED; urgency=medium
 
+  * annex.diskreserve default increased from 1 mb to 100 mb.
   * Include the assistant and webapp when building with cabal 3.4.1.0.
   * Merged the webapp build flag into the assistant build flag.
   * Optimise linker in linux standalone tarballs.
diff --git a/Types/GitConfig.hs b/Types/GitConfig.hs
index 22a299c480..44629d4126 100644
--- a/Types/GitConfig.hs
+++ b/Types/GitConfig.hs
@@ -153,7 +153,7 @@ extractGitConfig configsource r = GitConfig
 	, annexUUID = hereuuid
 	, annexNumCopies = configuredNumCopies
 		<$> getmayberead (annexConfig "numcopies")
-	, annexDiskReserve = fromMaybe onemegabyte $
+	, annexDiskReserve = fromMaybe (onemegabyte * 100) $
 		readSize dataUnits =<< getmaybe (annexConfig "diskreserve")
 	, annexDirect = getbool (annexConfig "direct") False
 	, annexBackend = maybe
diff --git a/doc/git-annex.mdwn b/doc/git-annex.mdwn
index b6dd730084..d95ec25f6b 100644
--- a/doc/git-annex.mdwn
+++ b/doc/git-annex.mdwn
@@ -822,12 +822,12 @@ repository, using [[git-annex-config]]. See its man page for a list.)
 * `annex.diskreserve`
 
   Amount of disk space to reserve. Disk space is checked when transferring
-  content to avoid running out, and additional free space can be reserved
-  via this option, to make space for more important content (such as git
-  commit logs). Can be specified with any commonly used units, for example,
-  "0.5 gb", "500M", or "100 KiloBytes"
+  annexed content to avoid running out, and additional free space can be
+  reserved via this option, to make space for other data (such as git 
+  commit logs). Can be specified with any commonly used units, for 
+  example, "0.5 gb", "500M", or "100 KiloBytes"
 
-  The default reserve is 1 megabyte.
+  The default reserve is 100 megabytes.
 
 * `annex.skipunknown`
 
diff --git a/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn b/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn
index f920a44826..75c6ad6153 100644
--- a/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn
+++ b/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn
@@ -9,6 +9,7 @@ be eaten up by other non-object uses of disk.
 
 Perhaps 1 mb is too small for the default for annex.diskreserve. Even
 10 or 100 mb would leave a lot more margin for other minor uses of disk space.
+(Update: increased default to 100 mb)
 
 Perhaps there could be another config like annex.diskreserve but that
 applies only to populating unlocked files. It could default to some larger

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_3_2a08321045a8ede5c3b5a690232020b3._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_3_2a08321045a8ede5c3b5a690232020b3._comment
new file mode 100644
index 0000000000..a5bb342722
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_3_2a08321045a8ede5c3b5a690232020b3._comment
@@ -0,0 +1,30 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 3"
+ date="2022-09-21T18:49:06Z"
+ content="""
+the workaround you suggest elsewhere for \"cosmetic\" problem works here too
+
+```
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+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:   .dandi/assets.json
+
+no changes added to commit (use \"git add\" and/or \"git commit -a\")
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git update-index -q --refresh .dandi/assets.json
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+nothing to commit, working tree clean
+
+```
+
+but since we are relying on output from `status`, it is not just a \"cosmetic\" issue. IMHO if such `update-index` is needed, it should have been done by git-annex automagically somehow/sometime.
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_2_49e075aaa89e60fe1d35513dd4d4d755._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_2_49e075aaa89e60fe1d35513dd4d4d755._comment
new file mode 100644
index 0000000000..d27645608b
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_2_49e075aaa89e60fe1d35513dd4d4d755._comment
@@ -0,0 +1,46 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 2"
+ date="2022-09-21T18:46:50Z"
+ content="""
+d'oh forgot to show that I have tried that one too. Here is everything at once again with `git diff` and again doing checksums (that should have been different in my prev examples as well if different only in tree but not in index):
+
+```shell
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+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:   .dandi/assets.json
+
+
+It took 3.19 seconds to enumerate untracked files. 'status -uno'
+may speed it up, but you have to be careful not to forget to add
+new files yourself (see 'git help status').
+no changes added to commit (use \"git add\" and/or \"git commit -a\")
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git diff
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git diff --cached
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ sha256sum .dandi/assets.json
+6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14  .dandi/assets.json
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git show -- .dandi/assets.json
+commit b859efed7ddb2ff31cc26168f40676c572d2798f (HEAD -> draft, github/draft, github/HEAD)
+Author: DANDI User <info@dandiarchive.org>
+Date:   Fri Sep 16 22:22:29 2022 +0000
+
+    [backups2datalad] 66 files added
+
+diff --git a/.dandi/assets.json b/.dandi/assets.json
+index d3ef95e1ee..62fe372810 100644
+--- a/.dandi/assets.json
++++ b/.dandi/assets.json
+@@ -1 +1 @@
+-/annex/objects/SHA256E-s69400783--8b576786d3926ab0e84809b4131cdc5a8f631674d378afa343e7dcd84f011c90.json
++/annex/objects/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json
+(dandisets) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git annex status
+M ./.dandi/assets.json
+
+```
+"""]]

diff --git a/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment b/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment
new file mode 100644
index 0000000000..cda22f3bd4
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-21T17:42:44Z"
+ content="""
+Gus, did you manage to recover from the situation?
+
+I did some experimenting to see what it looks like when this happens.
+Here I am in a filesystem with 76 mb free, and annex.diskreserve is set to
+75 mb. The "big" file is 100 mb in size:
+
+	joey@darkstar:~/mnt/r2>git pull
+	remote: Enumerating objects: 5, done.
+	remote: Counting objects: 100% (5/5), done.
+	remote: Compressing objects: 100% (3/3), done.
+	remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
+	Unpacking objects: 100% (3/3), 328 bytes | 328.00 KiB/s, done.
+	From /home/joey/tmp/bench/r
+	   2dc7cd3..3699920  master     -> origin/master
+	Updating 2dc7cd3..3699920
+	Fast-forward
+	 big | 2 +-
+	 1 file changed, 1 insertion(+), 1 deletion(-)
+	 mode change 120000 => 100644 big
+	  not enough free space, need 100.99 MB more (use --force to override this check or adjust annex.diskreserve)
+	  not enough free space, need 101 MB more (use --force to override this check or adjust annex.diskreserve)
+	git-annex: unable to populate worktree file ./big
+	  not enough free space, need 101.02 MB more (use --force to override this check or adjust annex.diskreserve)
+	git-annex: git status will show big to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh big
+	  not enough free space, need 101.02 MB more (use --force to override this check or adjust annex.diskreserve)
+	git-annex: git status will show big to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh big
+
+So git-annex avoids filling up the entire disk in this situation
+when annex.diskreserve is configured. I suppose that you don't have
+it configured, so it defaulted to only 1 mb -- and then other
+things than unlocked files used up that remaining space.
+
+I've opened to todo that would have avoided the worst of
+your experience:
+[[todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default]].
+"""]]
diff --git a/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn b/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn
new file mode 100644
index 0000000000..f920a44826
--- /dev/null
+++ b/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn
@@ -0,0 +1,17 @@
+As seen in [[forum/Not_enough_free_space]], pulling
+a commit that unlocks a lot of large files whose content is present in the
+repository can result in an unexpected doubling of the disk space used by
+git-annex.
+
+annex.diskreserve avoids that using up the entire disk, but it's not
+uncommon for users to not have it set, and the 1 mb default can easily
+be eaten up by other non-object uses of disk.
+
+Perhaps 1 mb is too small for the default for annex.diskreserve. Even
+10 or 100 mb would leave a lot more margin for other minor uses of disk space.
+
+Perhaps there could be another config like annex.diskreserve but that
+applies only to populating unlocked files. It could default to some larger
+size, like 1 gb. Probably most users are not going to want to populate
+unlocked files when their disk space gets that low. Although, the same
+could be argued about just getting files. --[[Joey]]

diff --git a/doc/forum/HTTP_uploads/comment_1_e22213816c53e6e3555532c452eceb49._comment b/doc/forum/HTTP_uploads/comment_1_e22213816c53e6e3555532c452eceb49._comment
new file mode 100644
index 0000000000..223a3cc30b
--- /dev/null
+++ b/doc/forum/HTTP_uploads/comment_1_e22213816c53e6e3555532c452eceb49._comment
@@ -0,0 +1,41 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-21T17:17:48Z"
+ content="""
+To upload over HTTP, there needs to be some HTTP endpoint accepting the
+upload. There is no "one true way" to upload a file to a HTTP server. There
+are several HTTP-based protocols that can be used for uploads 
+that git-annex supports, including common standards like
+[[special_remotes/webdav]] and
+[[special_remotes/S3]], and less common standards like
+[[special_remotes/git-lfs]].
+
+git-lfs is notable in that it can be used with a regular git remote, that
+happens to implement the git-lfs endpoint. No special remote needed. 
+You can use git-annex to upload to a git-lfs remote. One way to serve
+such a remote would be using gitlab.
+
+I don't want to add some additional git-annex specific HTTP-based protocol. I
+could see possibly adding support for uploading to git remotes using webdav,
+much the same as uploading to git-lfs remotes is handled now. But it does not
+seem common to have a webdav server that accepts uploads to the url of your git
+repository. Not like it's very common for git-lfs to be supported in a git
+repo, when using github or gitlab. It might be more common for a git repo to be
+hosted on S3, so maybe uploads to http remotes via S3 would make sense. But
+that still seems like a niche configuration.
+
+The reason you see HEADs is that before sending content to a remote,
+git-annex checks if the remote already contains it. It knows how to do that
+check for a HTTP remote, which it needs to be able to do for other reasons.
+So it gets that far before failing. (Doing the check also means that if the
+content had been copied to the HTTP remote in the meantime, 
+`git-annex copy --to` would actually succeed. So it's not entirely useless.)
+
+Note that, with the current version of git-annex, you get a different, and
+much better error message:
+
+	copy foo (to origin...)
+	  copying to non-ssh repo not supported
+	failed
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_1_5dead4bf9fe9a9c7627843c91613caf5._comment b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_1_5dead4bf9fe9a9c7627843c91613caf5._comment
new file mode 100644
index 0000000000..c13beab231
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not/comment_1_5dead4bf9fe9a9c7627843c91613caf5._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-21T17:05:51Z"
+ content="""
+Is .dandi/assets.json an unlocked file?
+
+`git diff --cached` seems like the wrong thing to run, because
+that would show changes that you have staged for commit.
+This change is one that has not been staged for commit.
+So `git diff` should show it.
+"""]]

diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_7_d44dea0d8c0d46dd8c75ae40f66072e1._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_7_d44dea0d8c0d46dd8c75ae40f66072e1._comment
new file mode 100644
index 0000000000..0c2dc3ee8d
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_7_d44dea0d8c0d46dd8c75ae40f66072e1._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-09-21T17:01:18Z"
+ content="""
+@nick.guenther importtree needs a way to list the files stored in a bucket,
+and doing that involves using the S3 API.
+
+In the case of your remote, it knows what files are stored in the
+bucket, since git-annex stored them there previously.
+"""]]

diff --git a/doc/git-annex-preferred-content/comment_6_ef4fad67d2e2c5044c8134e426c3d086._comment b/doc/git-annex-preferred-content/comment_6_ef4fad67d2e2c5044c8134e426c3d086._comment
new file mode 100644
index 0000000000..fa9a0aa00f
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_6_ef4fad67d2e2c5044c8134e426c3d086._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="rinomizu5@5ead4c82685c65d7717dbd5591b80425036ae9e3"
+ nickname="rinomizu5"
+ avatar="http://cdn.libravatar.org/avatar/62478823018c68821064febcda7e5d4f"
+ subject=""not inbackend=URL" is failed with parse error"
+ date="2022-09-21T07:04:55Z"
+ content="""
+I tried the `git annex wanted gin \"not inbackend=URL\"` because I don't want to sync to gin remote if the backend key is a URL. But it failed with a Parse error.  
+The syntax says `inbackend=name`, but is `URL` not included in this `name`?  
+Please advise me what to do.  
+
+
+"""]]

diff --git a/doc/git-annex-preferred-content/comment_5_b05949f87e0073e93a7e09658bd21f05._comment b/doc/git-annex-preferred-content/comment_5_b05949f87e0073e93a7e09658bd21f05._comment
new file mode 100644
index 0000000000..dcd5eb610a
--- /dev/null
+++ b/doc/git-annex-preferred-content/comment_5_b05949f87e0073e93a7e09658bd21f05._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="rinomizu5@5ead4c82685c65d7717dbd5591b80425036ae9e3"
+ nickname="rinomizu5"
+ avatar="http://cdn.libravatar.org/avatar/62478823018c68821064febcda7e5d4f"
+ subject=""not inbackend=URL" is failed with parse error"
+ date="2022-09-21T07:04:35Z"
+ content="""
+I tried the `git annex wanted gin \"not inbackend=URL\"` because I don't want to sync to gin remote if the backend key is a URL. But it failed with a Parse error.  
+The syntax says `inbackend=name`, but is `URL` not included in this `name`?  
+Please advise me what to do.  
+
+
+"""]]

diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_6_b1e14d6baef8d03aaa6ace717aebc0f9._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_6_b1e14d6baef8d03aaa6ace717aebc0f9._comment
new file mode 100644
index 0000000000..b5c7de5b02
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_6_b1e14d6baef8d03aaa6ace717aebc0f9._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="yarikoptic"
+ avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
+ subject="comment 6"
+ date="2022-09-20T22:50:46Z"
+ content="""
+interesting idea. May be my invocation is still incomplete (no host or datacenter) but with the following one I am still queried for the credentials:
+
+```
+git annex initremote s3-origin type=S3 importtree=yes encryption=none autoenable=true bucket=dandiarchive fileprefix=zarr-checksums/2ac71edb-738c-40ac-bd8c-8ca985adaa12/ public=yes publicurl=https://dandiarchive.s3.amazonaws.com/ signature=v4 storageclass=STANDARD port=443
+```
+
+or may be whenever you ran `initremote` you did have those credential variables exported already? ;)
+"""]]

diff --git a/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn
new file mode 100644
index 0000000000..ee7f06bf72
--- /dev/null
+++ b/doc/bugs/reports_file___34__modified__34___whenever_it_is_not.mdwn
@@ -0,0 +1,92 @@
+### Please describe the problem.
+
+git status reports having staged changes and no changes from index
+
+```shell
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+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:   .dandi/assets.json
+
+no changes added to commit (use "git add" and/or "git commit -a")
+
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git annex status
+M ./.dandi/assets.json
+```
+
+although git shows no diff and sha256 checksum corresponds to the key:
+
+```shell
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git diff --cached
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git show -- .dandi/assets.json
+commit b859efed7ddb2ff31cc26168f40676c572d2798f (HEAD -> draft, github/draft, github/HEAD)
+Author: DANDI User <info@dandiarchive.org>
+Date:   Fri Sep 16 22:22:29 2022 +0000
+
+    [backups2datalad] 66 files added
+
+diff --git a/.dandi/assets.json b/.dandi/assets.json
+index d3ef95e1ee..62fe372810 100644
+--- a/.dandi/assets.json
++++ b/.dandi/assets.json
+@@ -1 +1 @@
+-/annex/objects/SHA256E-s69400783--8b576786d3926ab0e84809b4131cdc5a8f631674d378afa343e7dcd84f011c90.json
++/annex/objects/SHA256E-s69507227--6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14.json
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ sha256sum .dandi/assets.json
+6a0a91c4158d316ab8ad9bd8ebf7579b9c3c579e1035c48134246b6a5d2f6f14  .dandi/assets.json
+```
+
+I think may be the tricky part is that I have it of 
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git config annex.version
+10
+```
+
+although I thought that we kept it at 8 but I have user wider config setting
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git config filter.annex.process
+git-annex filter-process
+```
+
+I was recommended to speed up operations while avoiding upgrade to  10, but I guess running most recent version once lead to the upgrade since all the other repos are still at 8 as I thought it would be
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ grep -h '\<version =' ../*/.git/config | sort | uniq -c
+      1         version = 10
+    186         version = 8
+```
+
+having it reported modified causes our script which does sanity check to operate only on clean repo to fail.
+
+`git reset --hard` seems mitigated that
+
+```
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git reset --hard
+HEAD is now at b859efed7d [backups2datalad] 66 files added
+(git-annex) dandi@drogon:/mnt/backup/dandi/dandisets/000026$ git status
+On branch draft
+Your branch is up to date with 'github/draft'.
+
+nothing to commit, working tree clean
+```
+
+all.  I will now rerun our script and see in what state I would end up (although, once again, I ended up in version 10 of the repo already, so may be behavior would be different). 
+
+### What steps will reproduce the problem?
+
+I think I get it after I `annex move` and then `annex get` that file back. Just for my own reference -- git-annex repo is result of the https://github.com/dandi/dandisets/blob/draft/tools/backups2datalad-update-cron 
+
+
+### What version of git-annex are you using? On what operating system?
+
+10.20220822-g84f1875 (conda build), originally observed on earlier 10.20220724-ge30d846
+
+
+[[!meta author=yoh]]
+[[!tag projects/dandi]]

diff --git a/doc/forum/HTTP_uploads.mdwn b/doc/forum/HTTP_uploads.mdwn
new file mode 100644
index 0000000000..c24180d9ee
--- /dev/null
+++ b/doc/forum/HTTP_uploads.mdwn
@@ -0,0 +1,133 @@
+Does git-annex support **uploading** over HTTP? I learned how to set up a public (anonymous, download-only) HTTP remote -- a regular git remote, **not** a special remote -- by following [[tips/setup_a_public_repository_on_a_web_site/]]. Now I also want private repos (so, non-anonymous downloads), and, for completeness, uploads.
+
+I know those Apache-based instructions don't cover those cases. I'm working on extending them. I've [ported those instructions into Gitea](https://github.com/neuropoly/gitea/pull/1), and now I can `git clone` with both gitea's SSH and HTTP URLs and `git annex get` works, and permissions are enforced on private repos.
+
+So I've got non-anonymous downloads covered. But how do I make `git annex sync --content` (or equivalently, `git annex copy --to origin`) upload when the remote is an HTTP URL? Does it know how? I've experimented and haven't been able to get it to work, but neither does it give me a clear error rejecting my attempt.
+
+
+```
+[kousu@nigiri CANDICE-fMRI-]$ git config annex.debug true
+[kousu@nigiri CANDICE-fMRI-]$ git annex copy --to origin
+[2022-05-08 02:52:23.217458919] (Utility.Process) process [28036] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","git-annex"]
+[2022-05-08 02:52:23.219000083] (Utility.Process) process [28036] done ExitSuccess
+[2022-05-08 02:52:23.219516464] (Utility.Process) process [28037] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","show-ref","--hash","refs/heads/git-annex"]
+[2022-05-08 02:52:23.221135085] (Utility.Process) process [28037] done ExitSuccess
+[2022-05-08 02:52:23.22179462] (Utility.Process) process [28038] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","log","refs/heads/git-annex..6c3b23ed5b89e73fdb170e4dfb3dc4f7324acd87","--pretty=%H","-n1"]
+[2022-05-08 02:52:23.224259745] (Utility.Process) process [28038] done ExitSuccess
+[2022-05-08 02:52:23.225976282] (Utility.Process) process [28039] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch"]
+[2022-05-08 02:52:23.228332152] (Utility.Process) process [28040] read: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","ls-files","--stage","-z","--error-unmatch","--"]
+[2022-05-08 02:52:23.229159541] (Utility.Process) process [28041] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch-check=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-05-08 02:52:23.22958377] (Utility.Process) process [28042] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[2022-05-08 02:52:23.230213916] (Utility.Process) process [28039] done ExitSuccess
+[2022-05-08 02:52:23.231313697] (Utility.Process) process [28043] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","cat-file","--batch=%(objectname) %(objecttype) %(objectsize)","--buffer"]
+[...]
+copy sub-BAN04/anat/sub-BAN02_T1w.nii.gz [2022-05-08 02:52:53.078448893] (Utility.Url) Request {
+  host                 = "data.praxisinstitute.org.dev.neuropoly.org"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("User-Agent","git-annex/10.20220322-g959beeea9")]
+  path                 = "/UofC/CANDICE-fMRI-.git/annex/objects/433/2b9/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2022-05-08 02:52:53.16577961] (Utility.Process) process [28097] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","credential","fill"]
+Username for 'https://data.praxisinstitute.org.dev.neuropoly.org': kousu
+Password for 'https://kousu@data.praxisinstitute.org.dev.neuropoly.org': 
+[2022-05-08 02:52:56.868778349] (Utility.Process) process [28097] done ExitSuccess
+[2022-05-08 02:52:56.869119387] (Utility.Url) Request {
+  host                 = "data.praxisinstitute.org.dev.neuropoly.org"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("Authorization","<REDACTED>"),("User-Agent","git-annex/10.20220322-g959beeea9")]
+  path                 = "/UofC/CANDICE-fMRI-.git/annex/objects/433/2b9/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2022-05-08 02:52:56.954725712] (Utility.Process) process [28098] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","credential","reject"]
+[2022-05-08 02:52:56.956656836] (Utility.Process) process [28098] done ExitSuccess
+[2022-05-08 02:52:56.957140664] (Utility.Url) Request {
+  host                 = "data.praxisinstitute.org.dev.neuropoly.org"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("User-Agent","git-annex/10.20220322-g959beeea9")]
+  path                 = "/UofC/CANDICE-fMRI-.git/annex/objects/93/kp/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2022-05-08 02:52:57.041148655] (Utility.Process) process [28099] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","credential","fill"]
+Username for 'https://data.praxisinstitute.org.dev.neuropoly.org': kousu
+Password for 'https://kousu@data.praxisinstitute.org.dev.neuropoly.org': 
+[2022-05-08 02:53:00.095495453] (Utility.Process) process [28099] done ExitSuccess
+[2022-05-08 02:53:00.095774849] (Utility.Url) Request {
+  host                 = "data.praxisinstitute.org.dev.neuropoly.org"
+  port                 = 443
+  secure               = True
+  requestHeaders       = [("Accept-Encoding",""),("Authorization","<REDACTED>"),("User-Agent","git-annex/10.20220322-g959beeea9")]
+  path                 = "/UofC/CANDICE-fMRI-.git/annex/objects/93/kp/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz/SHA256E-s6677912--29be5e1eef0d3b5fcd6817999c9055f6c088d58b37c7c09bb87c440fb8037c81.nii.gz"
+  queryString          = ""
+  method               = "HEAD"
+  proxy                = Nothing
+  rawBody              = False
+  redirectCount        = 10
+  responseTimeout      = ResponseTimeoutDefault
+  requestVersion       = HTTP/1.1
+  proxySecureMode      = ProxySecureWithConnect
+}
+
+[2022-05-08 02:53:00.183376947] (Utility.Process) process [28100] chat: git ["--git-dir=.git","--work-tree=.","--literal-pathspecs","credential","reject"]
+[2022-05-08 02:53:00.18501078] (Utility.Process) process [28100] done ExitSuccess
+(not found) failed
+[2022-05-08 02:53:00.185253039] (Utility.Process) process [28043] done ExitSuccess
+[2022-05-08 02:53:00.185356286] (Utility.Process) process [28042] done ExitSuccess
+[2022-05-08 02:53:00.185460462] (Utility.Process) process [28041] done ExitSuccess
+[2022-05-08 02:53:00.185552806] (Utility.Process) process [28040] done ExitSuccess
+copy: 4 failed
+```
+
+I observe that `git-annex` issues a HEAD request to find out of the file already exists (presumably, checking if it needs to be uploaded), hits the authwall, asks for and reissues the HEAD request with credentials, which _successfully_ gets a 404 -- I know by watching the server logs -- but then it says "(not found) failed". Then it reissues the same two requests for the hashdirmixed ([[internals/hashing]]) variant of the URLs.
+
+Why is it issuing a HEAD at all if it's not going to try to later send a PUT or a POST?
+
+I'm posting this in `forum` because I can't tell if this is a `bug` or a `wishlist` item. Is git-annex supposed to be able to upload over HTTP or not? It can upload to S3, why not to regular HTTP remotes? Would you be interested in exploring this feature if it doesn't yet exist?
+
+<details><summary>version</summary>
+
+```
+[kousu@nigiri ~]$ git annex version
+git-annex version: 10.20220504-g4e4c44ed8
+build flags: Assistant Webapp Pairing Inotify DBus DesktopNotify TorrentParser MagicMime Feeds Testsuite S3 WebDAV
+dependency versions: aws-0.22 bloomfilter-2.0.1.0 cryptonite-0.30 DAV-1.3.4 feed-1.3.2.1 ghc-9.0.2 http-client-0.7.11 persistent-sqlite-2.13.0.3 torrent-10000.1.1 uuid-1.3.15 yesod-1.6.2
+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 X*
+remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar git-lfs httpalso borg 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
+```
+
+</details>
+
+
+My motivation for HTTP uploads is that I want my users to be able to do everything using only one credential; special remotes imply adding an extra credential, and ssh remotes mean managing ssh keys. I know maybe it's less safe, but getting people to adopt this technology is already difficult due to the number of nearly identical but incompatible apps, and asking them to manage extra credentials is often the final breaking point. If I can say "just make up one password" it'll go down easier. Hopefully you can give me a clear answer about if this is/isn't/will/won't be a thing, and then I will know where to focus my efforts next :)
+
+Thanks!

diff --git a/doc/forum/Not_enough_free_space/comment_5_f8206862e22fa354d97cc3d9d2af8d5c._comment b/doc/forum/Not_enough_free_space/comment_5_f8206862e22fa354d97cc3d9d2af8d5c._comment
new file mode 100644
index 0000000000..ba66f1fa79
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_5_f8206862e22fa354d97cc3d9d2af8d5c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="Gus"
+ avatar="http://cdn.libravatar.org/avatar/665626c67ab3ee7e842183f6f659e120"
+ subject="comment 5"
+ date="2022-09-20T22:07:30Z"
+ content="""
+Thank you, helpful community, for your assistance.
+
+joey, I stand corrected regarding the documentation. I guess it was the magnitude of the consequences of that detail that took me by surprise.
+"""]]

diff --git a/doc/todo/allow_for_annonymous_AWS_S3_access/comment_5_b680494cd2fb1cf117b110e08e0ff476._comment b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_5_b680494cd2fb1cf117b110e08e0ff476._comment
new file mode 100644
index 0000000000..ee3191400c
--- /dev/null
+++ b/doc/todo/allow_for_annonymous_AWS_S3_access/comment_5_b680494cd2fb1cf117b110e08e0ff476._comment
@@ -0,0 +1,49 @@
+[[!comment format=mdwn
+ username="nick.guenther@e418ed3c763dff37995c2ed5da4232a7c6cee0a9"
+ nickname="nick.guenther"
+ avatar="http://cdn.libravatar.org/avatar/9e85c6ca61c3f877fef4f91c2bf6e278"
+ subject="comment 5"
+ date="2022-09-20T21:30:51Z"
+ content="""
+We are hosting two datasets on S3 that allows anonymous downloads: https://github.com/spine-generic/data-multi-subject, https://github.com/spine-generic/data-single-subject.
+
+You can try it right now:
+
+```
+p115628@joplin:~/datasets/t$ git clone https://github.com/spine-generic/data-multi-subject
+Clonage dans 'data-multi-subject'...
+remote: Enumerating objects: 123344, done.
+remote: Counting objects: 100% (26796/26796), done.
+remote: Compressing objects: 100% (19491/19491), done.
+remote: Total 123344 (delta 6052), reused 25545 (delta 5941), pack-reused 96548
+Réception d'objets: 100% (123344/123344), 15.50 Mio | 8.48 Mio/s, fait.
+Résolution des deltas: 100% (46253/46253), fait.
+p115628@joplin:~/datasets/t$ cd data-multi-subject/
+p115628@joplin:~/datasets/t/data-multi-subject$ git annex get
+(merging origin/git-annex into git-annex...)
+(recording state in git...)
+(scanning for unlocked files...)
+get derivatives/labels/sub-amu01/anat/sub-amu01_T1w_labels-disc-manual.nii.gz (from amazon...) 
+
+(checksum...) ok                  
+get derivatives/labels/sub-amu01/anat/sub-amu01_T1w_seg-manual.nii.gz (from amazon...) 
+
+(checksum...) ok                  
+get derivatives/labels/sub-amu01/anat/sub-amu01_T2star_seg-manual.nii.gz (from amazon...) 
+
+(checksum...) ok                  
+get derivatives/labels/sub-amu01/anat/sub-amu01_T2w_labels-disc-manual.nii.gz (from amazon...) 
+
+[...]
+```
+
+
+The trick was simply to set `public=yes` and `publicurl` when running `initremote`. The final config I have stored is
+
+```
+5a5447a8-a9b8-49bc-8276-01a62632b502 autoenable=true bucket=data-multi-subject---spine-generic---neuropoly datacenter=ca-central-1 encryption=none host=s3.ca-central-1.amazonaws.com name=amazon port=443 public=yes publicurl=https://data-multi-subject---spine-generic---neuropoly.s3.ca-central-1.amazonaws.com signature=v4 storageclass=STANDARD type=S3 timestamp=1661783824.374956s
+```
+
+
+Why would `importtree` behave so differently?
+"""]]

diff --git a/CHANGELOG b/CHANGELOG
index c054007290..56593f35cc 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -23,6 +23,10 @@ git-annex (10.20220823) UNRELEASED; urgency=medium
     that it had changed, due to only accepting the inode+mtime of one file
     (that was since modified or deleted) and not accepting the inode+mtime
     of other duplicate files.
+  * Fix a reversion that prevented git-annex from working in a
+    repository when --git-dir or GIT_DIR is specified to relocate the git
+    directory to somewhere else.
+    (Introduced in version 10.20220525)
 
  -- Joey Hess <id@joeyh.name>  Mon, 29 Aug 2022 15:03:04 -0400
 
diff --git a/Git/Config.hs b/Git/Config.hs
index 7fd096d1f8..7bf2793778 100644
--- a/Git/Config.hs
+++ b/Git/Config.hs
@@ -282,16 +282,20 @@ unset ck@(ConfigKey k) r = ifM (Git.Command.runBool ps r)
  - repo.
  -}
 checkRepoConfigInaccessible :: Repo -> IO Bool
-checkRepoConfigInaccessible r = do
-	-- Cannot use gitCommandLine here because specifying --git-dir
-	-- will bypass the git security check.
-	let p = (proc "git" ["config", "--local", "--list"])
-		{ cwd = Just (fromRawFilePath (repoPath r))
-		, env = gitEnv r
-		}
-	(out, ok) <- processTranscript' p Nothing
-	if not ok
-		then do
-			debug (DebugSource "Git.Config") ("config output: " ++ out)
-			return True
-		else return False
+checkRepoConfigInaccessible r
+	-- When --git-dir or GIT_DIR is used to specify the git
+	-- directory, git does not check for CVE-2022-24765.
+	| gitDirSpecifiedExplicitly r = return False
+	| otherwise = do
+		-- Cannot use gitCommandLine here because specifying --git-dir
+		-- will bypass the git security check.
+		let p = (proc "git" ["config", "--local", "--list"])
+			{ cwd = Just (fromRawFilePath (repoPath r))
+			, env = gitEnv r
+			}
+		(out, ok) <- processTranscript' p Nothing
+		if not ok
+			then do
+				debug (DebugSource "Git.Config") ("config output: " ++ out)
+				return True
+			else return False
diff --git a/Git/Construct.hs b/Git/Construct.hs
index a5e825e7c3..27123e337d 100644
--- a/Git/Construct.hs
+++ b/Git/Construct.hs
@@ -277,5 +277,6 @@ newFrom l = Repo
 	, gitEnv = Nothing
 	, gitEnvOverridesGitDir = False
 	, gitGlobalOpts = []
+	, gitDirSpecifiedExplicitly = False
 	}
 
diff --git a/Git/CurrentRepo.hs b/Git/CurrentRepo.hs
index 9261eabca1..bd1ab5cd4b 100644
--- a/Git/CurrentRepo.hs
+++ b/Git/CurrentRepo.hs
@@ -1,6 +1,6 @@
 {- The current git repository.
  -
- - Copyright 2012-2020 Joey Hess <id@joeyh.name>
+ - Copyright 2012-2022 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU AGPL version 3 or higher.
  -}
@@ -80,9 +80,10 @@ get = do
 			, worktree = Just curr
 			}
 		r <- Git.Config.read $ newFrom loc
-		return $ if Git.Config.isBare r
-			then r { location = (location r) { worktree = Nothing } }
-			else r
+		let r' = r { gitDirSpecifiedExplicitly = True }
+		return $ if Git.Config.isBare r'
+			then r' { location = (location r) { worktree = Nothing } }
+			else r'
 	configure Nothing Nothing = giveup "Not in a git repository."
 
 	addworktree w r = changelocation r $ Local
diff --git a/Git/Types.hs b/Git/Types.hs
index 68045fc027..ce1818e71c 100644
--- a/Git/Types.hs
+++ b/Git/Types.hs
@@ -51,6 +51,8 @@ data Repo = Repo
 	, gitEnvOverridesGitDir :: Bool
 	-- global options to pass to git when running git commands
 	, gitGlobalOpts :: [CommandParam]
+	-- True only when --git-dir or GIT_DIR was used
+	, gitDirSpecifiedExplicitly :: Bool
 	} deriving (Show, Eq, Ord)
 
 newtype ConfigKey = ConfigKey S.ByteString
diff --git a/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn b/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn
index 35d13758a2..dbc430b22c 100644
--- a/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn
+++ b/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn
@@ -18,3 +18,35 @@ Simple test case:
 
         failed
 
+And --debug shows:
+
+	[2022-09-20 14:17:56.238686901] (Utility.Process) process [1284622] read: git ["config","--local","--list"]
+	[2022-09-20 14:17:56.240836887] (Utility.Process) process [1284622] done ExitFailure 128
+	[2022-09-20 14:17:56.24107763] (Git.Config) config output: fatal: --local can only be used inside a git repository
+
+So passing --git-dir to that command will make it succeeed. The problem
+though is that passing --git-dir to that command also bypasses git's
+fix for CVE-2022-24765. The command would even succeed if the directory
+were owned by someone else then.
+
+	joey@darkstar:/tmp/foo>sudo chown -R root.root .
+	[sudo] password for joey:
+	joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles config --local --list
+	core.repositoryformatversion=0
+	core.filemode=true
+	core.bare=false
+	core.logallrefupdates=true
+	core.worktree=/tmp/foo
+	joey@darkstar:/tmp/foo>git config --local --list
+	fatal: --local can only be used inside a git repository
+
+But, if the user runs git-annex with an explicit --git-dir,
+it's actually ok for git-annex to bypass the CVE-2022-24765 check.
+Because --git-dir actually bypasses that check.
+
+So, the fix for this seems like it will involve it remembering
+when the git repo was originally specified using --git-dir (or `GIT_DIR`),
+and if so, guardSafeToUseRepo can skip the check, or pass --git-dir to
+`git config --local --list`.
+
+> [[fixed|done]] --[[Joey]]

diff --git a/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn b/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn
new file mode 100644
index 0000000000..35d13758a2
--- /dev/null
+++ b/doc/bugs/When_--git-dir_is_not_in_--work-tree.mdwn
@@ -0,0 +1,20 @@
+Bug report incorrectly originally posted in the forum as
+[[/forum/When_--git-dir_is_not_in_--work-tree]].
+
+Simple test case:
+
+        joey@darkstar:~/src/git-annex>cd /tmp
+        joey@darkstar:/tmp>mkdir foo
+        joey@darkstar:/tmp>cd foo
+        joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles --work-tree=`pwd` init
+        Initialized empty Git repository in /tmp/foo/.dotfiles/
+        joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles --work-tree=`pwd` annex init
+        init
+        git-annex: Git refuses to operate in this repository,
+        probably because it is owned by someone else.
+
+        To add an exception for this directory, call:
+                git config --global --add safe.directory /tmp/foo
+
+        failed
+
diff --git a/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_1_0169812633d92bed8883e903e03056e3._comment b/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_1_0169812633d92bed8883e903e03056e3._comment
new file mode 100644
index 0000000000..ddfa0d1338
--- /dev/null
+++ b/doc/forum/When_--git-dir_is_not_in_--work-tree/comment_1_0169812633d92bed8883e903e03056e3._comment
@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-20T18:08:29Z"
+ content="""
+Simpler test case:
+
+	joey@darkstar:~/src/git-annex>cd /tmp
+	joey@darkstar:/tmp>mkdir foo
+	joey@darkstar:/tmp>cd foo
+	joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles --work-tree=`pwd` init
+	Initialized empty Git repository in /tmp/foo/.dotfiles/
+	joey@darkstar:/tmp/foo>git --git-dir=`pwd`/.dotfiles --work-tree=`pwd` annex init
+	init  
+	git-annex: Git refuses to operate in this repository,
+	probably because it is owned by someone else.
+	
+	To add an exception for this directory, call:
+		git config --global --add safe.directory /tmp/foo
+	
+	failed
+
+Anything like this is clearly a bug.
+And this forum is not the place to file bug reports. Doing so risks
+it being forgotten about because who is going to go back and check old
+forum threads to see if they were a bug that didn't get fixed?
+
+Here, I opened a bug report: [[bugs/When_--git-dir_is_not_in_--work-tree]]
+"""]]

diff --git a/doc/forum/Web_interface_to_git-annex__63__/comment_1_371586edbeca15724121a5123bce66d6._comment b/doc/forum/Web_interface_to_git-annex__63__/comment_1_371586edbeca15724121a5123bce66d6._comment
new file mode 100644
index 0000000000..aebf504f7e
--- /dev/null
+++ b/doc/forum/Web_interface_to_git-annex__63__/comment_1_371586edbeca15724121a5123bce66d6._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2022-09-20T18:04:32Z"
+ content="""
+I don't know of such a thing that is explicitly web-based.
+
+See [[tips/file_manager_integration]] for how to set up
+several file managers to be able to do get/drop. I don't see any reason
+some web-based file manager couldn't have similar hooks to the ones used
+there.
+"""]]

diff --git a/doc/todo/does_not_preserve_timestamps/comment_14_9a3f50f1b8cfd1cc0da83937a36e1369._comment b/doc/todo/does_not_preserve_timestamps/comment_14_9a3f50f1b8cfd1cc0da83937a36e1369._comment
new file mode 100644
index 0000000000..a48afdc01d
--- /dev/null
+++ b/doc/todo/does_not_preserve_timestamps/comment_14_9a3f50f1b8cfd1cc0da83937a36e1369._comment
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 14"""
+ date="2022-09-20T17:55:45Z"
+ content="""
+Note that `git-annex add` does preserve the timestamp of the file
+while adding it to the annex. Much the same as a file's timestamp is
+the same after `git add` as it was before running that command.
+When `git-annex add` replaces a file with a symlink, it even makes the
+symlink's timestamp be the same as the original file.
+
+What git-annex does not do is try to store the timestamp in git and arrange
+for clones that receive the file to get the same timestamp. There are lots
+of things like this that someone *might* want git to preserve, but git
+doesn't, and it's out of scope for git-annex to try to work around git's
+limitations in these areas. Plenty of room for other tools that add
+git tracked timestamps, etc. Many such tools exist.
+"""]]

diff --git a/doc/todo/does_not_preserve_timestamps.mdwn b/doc/todo/does_not_preserve_timestamps.mdwn
index 0d8f2371d4..c0b3667b03 100644
--- a/doc/todo/does_not_preserve_timestamps.mdwn
+++ b/doc/todo/does_not_preserve_timestamps.mdwn
@@ -14,3 +14,5 @@ Downloaded binary package dated 13/09/2014 amd64 Ubuntu 14.04.
 Files are in sync. For example, I move a file from a directory to my synced annex directory. It contains timestamp of 01/01/2010 for example. Once the file gets transferred to the remote computer, it gets current time, for example 20/09/2014 rather than keeping 01/01/2010. 
 
 All computers are linux based, ext4 filesystems. File transfers are done through shared encryption rsync remote.
+
+> [[wontfix|done]] --[[Joey]]

diff --git a/doc/forum/Not_enough_free_space/comment_3_c6ad0934136448a014f6b1c317bba3e6._comment b/doc/forum/Not_enough_free_space/comment_3_c6ad0934136448a014f6b1c317bba3e6._comment
new file mode 100644
index 0000000000..da7bdac67a
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_3_c6ad0934136448a014f6b1c317bba3e6._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2022-09-20T17:37:53Z"
+ content="""
+I think that the documentation of [[git-annex-unlock]] is pretty clear
+about this:
+
+       Unlocking a file changes how it is stored in the git repository
+       (from a symlink to a pointer file), so this command will make
+       a change that you can commit.
+
+To get the equivilant of the old direct mode, where files are unlocked in
+one repository without affecting other clones, use `git-annex adjust --unlock`.
+"""]]
diff --git a/doc/forum/Not_enough_free_space/comment_4_c05f95ae6d69cdc214a2b31ebc296a3b._comment b/doc/forum/Not_enough_free_space/comment_4_c05f95ae6d69cdc214a2b31ebc296a3b._comment
new file mode 100644
index 0000000000..cdce83bd34
--- /dev/null
+++ b/doc/forum/Not_enough_free_space/comment_4_c05f95ae6d69cdc214a2b31ebc296a3b._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 4"""
+ date="2022-09-20T17:43:18Z"
+ content="""
+Since unlocking makes a change to a file that git can commit,
+you can certianly find the commit that made this change if you look hard
+enough. Probably not one of the merge commits themselves, but one of the
+commits that was merged. I'd maybe try `git log -u` on a file that I know
+has otherwise not changed for a while. When the diff shows
+that the mode of the file has changed from 120000 to 100644,
+that's the change from a locked symlink to an unlocked file.
+
+To disable the smudge/clean filters, edit `.git/config`
+and delete the block of config under `[filter "annex"]`
+"""]]

diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates.mdwn b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates.mdwn
index 971fd089f3..e5411b3d9d 100644
--- a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates.mdwn
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates.mdwn
@@ -50,3 +50,5 @@ Original conversation was at [[/bugs/Files_recorded_with_other_file__39__s_check
 ### 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)
 
 Yes!  I used it for awhile with the assistant to sync a lot of files.
+
+> [[fixed|done]] --[[Joey]]
diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_7_4a1248ea257c04f1afe233891a606eea._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_7_4a1248ea257c04f1afe233891a606eea._comment
new file mode 100644
index 0000000000..b023e3c6f6
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_7_4a1248ea257c04f1afe233891a606eea._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 7"""
+ date="2022-09-20T17:35:10Z"
+ content="""
+Ok, fixed that. I'm confident this will fix the issue for you, so closing.
+"""]]

diff --git a/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment
new file mode 100644
index 0000000000..848f170302
--- /dev/null
+++ b/doc/bugs/Incorrect___34__file_content_has_changed__34___on_duplicates/comment_6_4d05a896fd57b55388fb21638ed02233._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 6"""
+ date="2022-09-20T16:42:18Z"
+ content="""
+Ah, here's the smoking gun: In Remote.Helper.ExportImport,
+it gets the cids for a key. And promptly picks the first one to pass to
+retrieveExportWithContentIdentifier, ignoring all the rest.
+It also gets the first recorded export location and likewise passes it to
+retrieveExportWithContentIdentifier.
+
+It seems like a fix would be to try retrieveExportWithContentIdentifier
+with each combination of cid and export location. But that would cause an
+`O(N^2)` explosion and it's possible a remote has say 1000 empty files in
+it.
+
+Maybe instead make retrieveExportWithContentIdentifier take a list of valid
+cids, and accept any one of them? Then it would only need to be tried on
+each export location in turn until one succeeds. 
+
+(Hm, removeExportWithContentIdentifier and 
+checkPresentExportWithContentIdentifier already use a list, so similar problems
+are avoided with them.)
+"""]]