Added a comment: There is already something like fullsync: `git annex assist`, sugges...

diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_7_20febad4aa06d5b39668a858d2b118b1._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_7_20febad4aa06d5b39668a858d2b118b1._comment
new file mode 100644 (file)
index 0000000..d6170ac
--- /dev/null
+++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_7_20febad4aa06d5b39668a858d2b118b1._comment
@@ -0,0 +1,33 @@
+[[!comment format=mdwn
+ username="nobodyinperson"
+ avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
+ subject="There is already something like fullsync: `git annex assist`, suggestion: new `metasync` command"
+ date="2023-07-12T11:15:26Z"
+ content="""
+>  But would certainly support there being another command that did a \"Dropbox like full sync\".
+
+You might have missed it above, but `git annex assist` is **exactly** that new command that does a 'Dropbox-like sync' (adding new files, adding changes, metadata sync, content sync) and as OP suggested with `fullsync`. It is there, it works, it's wonderful. I think we can put that part of the discussion to rest.
+
+> Personally I'd really really prefer that \"sync\" stayed doing the same thing it's done for a decade: meta data sync, only. 
+
+Actually, `git annex sync` isn't always **just** metadata sync. If you're in a repo where someone (anyone!) decided to run `git annex config --set annex.synccontent true`, there flies your Terabytes of content around when you do your `git annex sync`, assuming it's metadata-only. At first I was a fan of teaching `git annex sync` everything with flags and configs, but I think joey is right that this is inconsistent and leads to surprises.
+
+If we're at it, we could get rid of the ambiguous `sync` command altogether (this is what joey also proposed for the very long run) and introduce a metadata-only sync command (`metasync`?) that **can't** sync content. Not with a setting, not with a flag, it just can't. Then that's perfect for those who only want to sync metadata and `get` files they want manually and without preferred content expressions (I suppose that's how you do it?).
+
+How about:
+
+- `git annex assist` (exists, works):
+  - syncs everything: metadata&content, leaves the repo completely clean and all participating remotes updated to the same state 
+  - for those who don't want to run the assistant, but still have 'one command to sync it all' whenever they feel like it or want to specify a custom commit message. 
+  - Preferred content expressions manage what files land where.
+  - Very important for newcomers as this will effectively be the only command they'll need to know to get a workflow started.
+- `git annex metasync` (new proposal): 
+  - basically `git annex sync --no-content` that **can't** ever sync content. No surprises through configs.
+  - Leaves the repo in a clean state and all connected remotes at the same state of metadata (the git stuff). Also adds new files! People who want more control should use the manual commands `git annex add|push|pull|etc.`.
+  - Option-wise as 'dumb' as `git annex assist'
+  - for those who never want automatic content syncing but `get|copy|move|...` stuff manually and don't want to fiddle with preferred content expressions
+  - current users of 'old' `git annex sync` without content syncing will eventually switch to this.
+- `git annex sync` (exists, has many options and configs): 
+  - roll back to non-content-syncing as before, for those that don't want to change their workflows yet
+  - deprecated eventually (in many years), with a big warning upon execution now already.
+"""]]