Added a comment: History of change

diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_5_da9812dd37de7bba4fe2b1785bdca1ae._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_5_da9812dd37de7bba4fe2b1785bdca1ae._comment
new file mode 100644 (file)
index 0000000..96df7c5
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_5_da9812dd37de7bba4fe2b1785bdca1ae._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="History of change"
+ date="2023-07-12T10:27:43Z"
+ content="""
+Thanks for the [pointer to the earlier bug discussing changing sync entirely](https://git-annex.branchable.com/todo/Having___39__git_annex_sync__39___optionally_add) @nobodyinperson; it's at least useful to have a reference for where all this breaking change suddenly came from given it's otherwise undocumented.  I've added a back pointer comment to that bug pointing at this one, as they're clearly related discussion (and it wasn't obvious the other \"sync\" bug was at all related to the change).
+
+I still strongly disagree with changing \"sync\" to do something pretty different from what it's done for 10 years being a good idea.  But would certainly support there being *another* command that did a \"Dropbox like full sync\".
+
+(Personally I'd really really prefer that \"sync\" stayed doing the same thing it's done for a decade: meta data sync, only.  If we're going to have to run a new different command just to retain core \"meta data sync\" behaviour, I guess \"git annex sync --no-content\" is not much worse than any other command we'd have to remember to suddenly use instead starting version N + 1.)
+
+Ewen
+"""]]