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

Added a comment

Browse source
This commit is contained in:
nobodyinperson 2023-07-17 06:12:27 +00:00 committed by admin
parent 0dc8b03588
commit 64edb19328
1 changed files with 12 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_18_594ae4ce426c7fd9963a22def58904d8._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="nobodyinperson"
avatar="http://cdn.libravatar.org/avatar/736a41cd4988ede057bae805d000f4f5"
subject="comment 18"
date="2023-07-17T06:12:26Z"
content="""
> I think the current warning on sync without --no-content could be removed (as the effective default change from the historical defaults is small)
The effect in term of file location will be the same after a `git annex symc` (with `present` as new defsult - or let's call it fallback - preferred content expression) and a `git annex sync --content`. **But**: There's one thing that `--content` also changes in terms of UX: speed/runtime. In my large annex repos with many files (~5 figures), a `git annex sync --content` takes *much* longer, even if no content is eventually synced. Git Annex apparently needs to go through all files whether they want to be copied somewhere. **Maybe a short-circuit path could be introduced here when all preferred content expressions effectively turn out to be `present`**. Users might wonder why `git annex sync` suddenly takes so long now.
In general, **a progress bar or if that's impossible another indication of what's going on between metadata syncing and content syncing** would be helpful. With this, I could agree that the warning can go away for a simple `git annex sync` with no preferred content expressions set.
"""]]