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

Added a comment: Alternative proposal for better backwards compatibility

Browse source
This commit is contained in:
ewen 2023-07-12 12:48:04 +00:00 committed by admin
parent f23993261b
commit 98f1eb48ea
1 changed files with 43 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

43
doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_8_84d31b8fdde0f0ab0355a5d30760e90d._comment Normal file
View file

@ -0,0 +1,43 @@
[[!comment format=mdwn
username="ewen"
avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e"
subject="Alternative proposal for better backwards compatibility"
date="2023-07-12T12:48:03Z"
content="""
Firstly, if `git annex assist` has been added to create the magical \"Dropbox like experience\", I don't see the need for changing the default behaviour of `git annex sync` at all. (For the record I'm glad `git annex assist` exists; I don't need it, or want it, but it clearly solves a bunch of UI problems for some users, and that's great. This is entirely about backwards incompatible UX changes in existing commands.)
Secondly, your (@nobodyinperson) suggestion for \"improving\" the current situation seems to be:
1. Entirely remove `git annex sync` (entirely breaking backwards compatiblity) and/or have it permanently display a warning that cannot be removed (annoying, incompatible with anything looking at output); and
2. Add a new (ie, not in any older version) `git annex metasync` which has some of the existing functionality, and some random other (unwanted by me at least) additional functionality (auto-adding any files in a directory where git annex is run, which I definitely do not want)
Which, to me, is *even more* breaking the user experience of using `git annex` for the last 8 years, than is currently happening. AFAICT there would then be *no way* at all to get the `git annex` \"just sync metadata without other unwanted behaviour\" that existed before. *And* it'd then require git annex version detection in scripts to tell if `git annex metadata --no-add-really-just-copy-metadata-honest` was available or not, or if one had to fall back to an old version of the command, which is a really user-hostile way to \"retain\" existing behaviour. (FTR in my case at least there is *zero* chance that `git annex sync` would suddenly encounter `annex.synccontent=true`, as it's just me, and I haven't set that; I don't need a \"guarantees\" it won't copy content option, except as a defense against the git annex defaults suddenly changing after 8 years.)
My suggestion for preserving backwards compatibilty would be:
1. Move the behaviour change out of `git annex sync` and into `git annex init` (rationale: it's run once per annex/machine pair, not many times per day/week, *and* it makes the change \"new annexes only\" which is much closer to \"opt in\")
2. From git annex version N + 1, have git annex automatically set `annex.synccontent=true` at `git annex init` of a *new* repo (ie, not just naming the local copy of the annex), and for version N+1 to N+3 (or higher) have `git annex init` issue a warning it has defaulted sync content on now (unlike earlier versions), and describe how to find out how to turn it off (unless a global git setting is making `annex.synccontent=true` the user preferred default anyway, in which case the user doesn't need a warning of a setting matching their preferred option).
3. For any annex where `annex.synccontent` is *not* set, assume it's an older annex, and use the backwards compatible, historical, default (false) *without* issuing any warnings about \"this is going to change\" (and never change that behaviour for historical annexes)
4. Retain `git annex sync` forever, with it obeying `annex.synccontent` (default: false, but set to true in newly created annexes by default)
5. Remove the newly added warning in `git annex sync` entirely, and just keep the functionality of the version before 10.20230623
This would:
1. Allow changing the `git annex sync` default from `metadata only` to `full content` in a \"new usage, opt in only\" way
2. Provide a clear path to opt out, and a clear path to opt in existing repos to match
3. Avoid needing to issue warnings to users on every run of a very core command until they set config
4. Avoid breaking existing usage, and use cases
The git annex \"meta data sync\" dance (which effectively allows `git push` into a repo that has a working directory attached, something that is normally otherwise difficult) was great, and the thing which made git annex attractive to me over other options. It'd be a shame to render that great functionality unreachable without unwanted \"some users wanted this, so all users must have this\" functionality.
Ewen
PS: `git annex push` / `git annex pull` do not appear to be meta data only tools to replace sync; they appear to be very explicitly targetted at copying content, and to be one remote at at a time as well (where as sync is \"all known remotes\"). Historically it looks like my wrapper scripts use `git annex get ...` to retrieve content, and `git annex copy --to=REMOTE ...` to put content onto a specific remote (ie, a `put`, when there is no `put`).
"""]]