Added a comment

diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_18_594ae4ce426c7fd9963a22def58904d8._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_18_594ae4ce426c7fd9963a22def58904d8._comment
new file mode 100644 (file)
index 0000000..ff734a4
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_18_594ae4ce426c7fd9963a22def58904d8._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="comment 18"
+ date="2023-07-17T06:12:26Z"
+ content="""
+> I think the current warning on sync without --no-content could be removed (as the effective default change from the historical defaults is small)
+
+The effect in term of file location will be the same after a `git annex symc` (with `present` as new defsult - or let's call it fallback - preferred content expression) and a `git annex sync --content`. **But**: There's one thing that `--content` also changes in terms of UX: speed/runtime. In my large annex repos with many files (~5 figures), a `git annex sync --content` takes *much* longer, even if no content is eventually synced. Git Annex apparently needs to go through all files whether they want to be copied somewhere. **Maybe a short-circuit path could be introduced here when all preferred content expressions effectively turn out to be `present`**. Users might wonder why `git annex sync` suddenly takes so long now.
+
+In general, **a progress bar or if that's impossible another indication of what's going on between metadata syncing and content syncing** would be helpful. With this, I could agree that the warning can go away for a simple `git annex sync` with no preferred content expressions set.
+"""]]