Added a comment: unspecified default preferred content = present

diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_17_d60adea3f0c0030a403c33c57f27abda._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_17_d60adea3f0c0030a403c33c57f27abda._comment
new file mode 100644 (file)
index 0000000..61bbf12
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_17_d60adea3f0c0030a403c33c57f27abda._comment
@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="ewen"
+ avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
+ subject="unspecified default preferred content = present"
+ date="2023-07-17T00:50:09Z"
+ content="""
+I would also be in favour of changing the default preferred content expression to be \"present\" at the same time as `sync` was changed to automatically sync content as well as metadata.  The effective user experience of a user with the existing default out of box configuration would be basically equivalent (now: `sync` does not sync content by default; then: `sync` will sync content if a policy to indicate desired content is set, but the default policy is \"whatever is here is correct\").
+
+If that change were made (default preferred content expression is \"present\") then:
+
+*  I think the current warning on `sync` without `--no-content` could be removed (as the effective default change from the historical defaults is small)
+
+*  There should probably be a warning on `git annex sync` *with* a preferred content policy explicitly set (*other than* `present`, the new default), that the `sync` without `--no-content` will \"soon\" automatically include that preferred content
+
+*  There should probably be a warning on `git annex sync --content` where there is no preferred content policy explicitly set, that the default preferred content policy is changing, and the user should set an explicit one
+
+That should result in \"I do everything manually\" users (who haven't set a preferred content policy, or set it to `present`) having basically \"no effective change\".  And the special cases of users (relying on the default `sync` not including their preferred content policy; relying on the existing default preferred content policy to work with `git annex sync --content`) get a reminder they'll need a smaller tweak to their config.
+
+I'd also be fine if *new* git annexes (ie `git annex init` after new release) were to set an explicit preferred content policy to the current default (just leaving \"no content policy set\" as the implied `present` suggested above).  So new annexes would still get the \"gets everything by default\" behaviour that it seems some users want.  (I do *not* want everything by default as almost always I use annexes for content that is too large to keep on my laptop/desktop.)
+
+Thanks for considering reducing the size of the UX change here.
+
+Ewen
+"""]]