comment
authorJoey Hess <joeyh@joeyh.name>
Sat, 15 Jul 2023 16:28:32 +0000 (12:28 -0400)
committerJoey Hess <joeyh@joeyh.name>
Sat, 15 Jul 2023 16:28:32 +0000 (12:28 -0400)
doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_15_38a0eafe91e05a7784dd5e305f38a8f3._comment [new file with mode: 0644]

diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_15_38a0eafe91e05a7784dd5e305f38a8f3._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_15_38a0eafe91e05a7784dd5e305f38a8f3._comment
new file mode 100644 (file)
index 0000000..a2e6d36
--- /dev/null
@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 15"""
+ date="2023-07-15T16:09:46Z"
+ content="""
+My current thinking is that when a repository does not have a preferred
+content expression, a content sync could avoid adding content to it. 
+
+This would avoid surprising behavior after the transition, except for 
+repositories that did at some time have a preferred content expression set,
+but one that no longer reflects the use of the repository.
+
+However, current users of `sync --content` (or of annex.synccontent) do
+expect it to fill their repositories that don't have preferred content
+configured. So would a sync that defaults to content syncing then need to
+behave differently than an explicit `sync --content`? Or should changing
+behavior in that case also be part of the transition?
+"""]]