diff --git a/doc/bugs/git_checkout_slow_with_unlocked_files.mdwn b/doc/bugs/git_checkout_slow_with_unlocked_files.mdwn
index 6f99b87f9c..5861f52777 100644
--- a/doc/bugs/git_checkout_slow_with_unlocked_files.mdwn
+++ b/doc/bugs/git_checkout_slow_with_unlocked_files.mdwn
@@ -26,3 +26,5 @@ Doing a `git checkout .` at this point took about a minute. In comparison doing
 ### Please provide any additional information below.
 
 The relevance of this problem is that I tried to go from a lock-adjusted branch to its basis with about 50000 unlocked files with `git checkout`. It was taking longer than expected and there were many warnings about a cosmetic problem and advised me to run `git update-index -q --refresh <path>`. Eventually I deleted the entire working tree, did `git reset --hard` to recreate the unlocked file stubs, locked every file and unlocked them again.
+
+> [[dup|done]] --[[Joey]]
diff --git a/doc/bugs/git_checkout_slow_with_unlocked_files/comment_1_80d9a46c608117fb9a381c59d4605ff4._comment b/doc/bugs/git_checkout_slow_with_unlocked_files/comment_1_80d9a46c608117fb9a381c59d4605ff4._comment
new file mode 100644
index 0000000000..693da1161a
--- /dev/null
+++ b/doc/bugs/git_checkout_slow_with_unlocked_files/comment_1_80d9a46c608117fb9a381c59d4605ff4._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2021-11-02T17:58:27Z"
+ content="""
+This is due to [[todo/git_smudge_clean_interface_suboptiomal]].
+"""]]
diff --git a/doc/todo/git_smudge_clean_interface_suboptiomal.mdwn b/doc/todo/git_smudge_clean_interface_suboptiomal.mdwn
index 319d8ee8a1..e4e20d7612 100644
--- a/doc/todo/git_smudge_clean_interface_suboptiomal.mdwn
+++ b/doc/todo/git_smudge_clean_interface_suboptiomal.mdwn
@@ -122,3 +122,28 @@ The best fix would be to improve git's smudge/clean interface:
 > 
 > If this was possible, it should speed up git checkout etc which use the
 > smudge filter. --[[Joey]]
+
+> > Tried that, it looks like when the long-running filter process
+> > sends only capability=smudge, and not clean, git add does not
+> > fall back to running filter.annex.clean. So unfortunately,
+> > it's not that easy.
+> >
+> > To proceed down this path, git-annex would need to use
+> > the long-running filter process for clean too. So `git add`
+> > would end up piping the whole content of large files over to git-annex,
+> > which would have to read and discard that data. This would
+> > probably make git-annex twice as slow for large files, although
+> > it would speed up git add of many small files. git-annex add
+> > could be used to work around any speed impact.
+> > 
+> > Or git could be extended
+> > with a capability in the protocol that lets the clean filter read the
+> > file content from disk, rather than having it piped into it. The
+> > long-running filter process protocol does have a design that would let
+> > it be extended that way.
+> >
+> > Or, I suppose git could be changed to run the clean filter when
+> > the long-running process does not support capability=clean. Maybe
+> > that would be more appealing to the git devs. Although since
+> > it currently does not run it, git-annex would need to somehow
+> > detect the old version of git and still work. --[[Joey]]