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:
jkniiv 2023-07-12 17:30:52 +00:00 • committed by admin
parent b6314c0207
commit 749b532e8f
1 changed files with 48 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

48
doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment Normal file
View file

@ -0,0 +1,48 @@
[[!comment format=mdwn
username="jkniiv"
avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d"
subject="comment 12"
date="2023-07-12T17:30:52Z"
content="""
(...continued)
@ewen:
> 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
Sounds good. I like the concept of an opt-in the way you laid it out. It's well thought out.
> 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
(Yes, that warning is annoying to say the least.)
I'm willing to accept some breakage to my workflows but I'd rather still see a separate
`git annex add`, `git commit -m ...` and \"sync metadata with one command\" workflow being supported.
The name of that sync command is not that important for me but I understand why it is for you.
> 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.
I agree to the strongest degree. I'm not a very good git user, but the core parts of git-annex
like `add` and `sync` have made me feel comfortable to a greater extent than the porcelain of core git.
I'm sure I can adapt to newfangled ways of doing my routine things with git-annex but as on \"old dog\" I'd
rather not adopt those new ways if I can avoid it.
"""]]