[[!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.
"""]]
