mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Added a comment: There is already something like fullsync: git annex assist, suggestion: new metasync command

Browse source
This commit is contained in:
nobodyinperson 2023-07-12 11:15:26 +00:00 committed by admin
parent 0386845605
commit d030ed8eb9
1 changed files with 33 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

33
doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_7_20febad4aa06d5b39668a858d2b118b1._comment Normal file
View file

@ -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.
"""]]