diff --git a/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_3_39d7b5588595067332909c53b232c413._comment b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_3_39d7b5588595067332909c53b232c413._comment
new file mode 100644
index 0000000000..73785d7e55
--- /dev/null
+++ b/doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_3_39d7b5588595067332909c53b232c413._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2023-02-08T16:29:36Z"
+ content="""
+Another time it would make sense to update the view is after git pull from
+elsewhere, which could change the metadata, or change the files present in
+the parent branch. I think it would make sense for `git-annex sync` run in
+a view to update the view after pulling.
+
+Updating the branch after `git-annex metadata` is run locally is of course
+also possible. There is a similarity to updating an adjusted branch after
+get/drop. Which has a config annex.adjustedbranchrefresh to tune how
+frequently to update the branch. Or the user could just run
+`git-annex sync --no-pull --no-push` themselves.
+
+There is probably a lot of scope for optimisation in updating the view
+branch, that might be able to get it reasonably quick. 
+I have not fully thought through it, but basically diffing from the old
+parent branch to the new parent to find files that have changed, and
+adding/removing those from the view. And also diffing from the old
+git-annex branch tree to the new one to get changes to metadata logs,
+parsing those and using changes to metadata to also move/delete/add
+files to the view branch.
+
+But it would be ok to start with a simple, slow implementation.
+"""]]