From 749b532e8ff424db4687d6cef4e0e368aeaaaa9c Mon Sep 17 00:00:00 2001 From: jkniiv <jkniiv@web> Date: Wed, 12 Jul 2023 17:30:52 +0000 Subject: [PATCH] Added a comment --- ..._4e0746d00d8a596d878c1fe12ec68849._comment | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment new file mode 100644 index 0000000000..43a368a7f1 --- /dev/null +++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_12_4e0746d00d8a596d878c1fe12ec68849._comment @@ -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. + +"""]]