comment

diff --git a/doc/todo/new_command_for_syncing_content_only/comment_7_084e139c8325bb8607f6c0a9f3873afe._comment b/doc/todo/new_command_for_syncing_content_only/comment_7_084e139c8325bb8607f6c0a9f3873afe._comment
new file mode 100644 (file)
index 0000000..36ebe85
--- /dev/null
+++ b/doc/todo/new_command_for_syncing_content_only/comment_7_084e139c8325bb8607f6c0a9f3873afe._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""Re: numcopies question"""
+ date="2023-07-05T21:22:10Z"
+ content="""
+It won't send content that is otherwise not wanted just to satisfy
+numcopies. Of course, like all commands, it refuses to drop a file if
+numcopies is not satisfied.
+
+Comsider a remote foo that only wants `include=foo/*`. And another remote 
+bar that wants `include=bar/*`. And numcopies=2. If `git-annex satisfy`
+was only able to access foo, and worked to satisfy numcopies, foo would end
+up with files in bar/* that it doesn't want. But there's a better
+place for those files to go, namly bar, which wants them. So over time it
+would do a large amount of unncessary work, sending files to foo, only
+to later drop those same files from foo once it was able to populate bar.
+
+If the user wants to, they can configure foo to want
+`include=foo/* or lackingcopies=1` and then `git-annex satisfy` will know
+this is a repository that wants any files that don't have enough copies,
+and when bar is not accessible, it will send its files to foo.
+
+I think this could stand to be better documented. Especially since
+things like `git-annex copy --auto` *do* work to satisfy numcopies in
+addition to preferred content.
+"""]]