Added a comment: unspecified default preferred content = present

This commit is contained in:
ewen 2023-07-17 00:50:09 +00:00 committed by admin
parent f504781127
commit 0dc8b03588

View file

@ -0,0 +1,24 @@
[[!comment format=mdwn
username="ewen"
avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
subject="unspecified default preferred content = present"
date="2023-07-17T00:50:09Z"
content="""
I would also be in favour of changing the default preferred content expression to be \"present\" at the same time as `sync` was changed to automatically sync content as well as metadata. The effective user experience of a user with the existing default out of box configuration would be basically equivalent (now: `sync` does not sync content by default; then: `sync` will sync content if a policy to indicate desired content is set, but the default policy is \"whatever is here is correct\").
If that change were made (default preferred content expression is \"present\") then:
* I think the current warning on `sync` without `--no-content` could be removed (as the effective default change from the historical defaults is small)
* There should probably be a warning on `git annex sync` *with* a preferred content policy explicitly set (*other than* `present`, the new default), that the `sync` without `--no-content` will \"soon\" automatically include that preferred content
* There should probably be a warning on `git annex sync --content` where there is no preferred content policy explicitly set, that the default preferred content policy is changing, and the user should set an explicit one
That should result in \"I do everything manually\" users (who haven't set a preferred content policy, or set it to `present`) having basically \"no effective change\". And the special cases of users (relying on the default `sync` not including their preferred content policy; relying on the existing default preferred content policy to work with `git annex sync --content`) get a reminder they'll need a smaller tweak to their config.
I'd also be fine if *new* git annexes (ie `git annex init` after new release) were to set an explicit preferred content policy to the current default (just leaving \"no content policy set\" as the implied `present` suggested above). So new annexes would still get the \"gets everything by default\" behaviour that it seems some users want. (I do *not* want everything by default as almost always I use annexes for content that is too large to keep on my laptop/desktop.)
Thanks for considering reducing the size of the UX change here.
Ewen
"""]]