From e7f59c4ca4653132fdca1405cb57c7cfb864c9ad Mon Sep 17 00:00:00 2001 From: ewen Date: Wed, 12 Jul 2023 10:21:04 +0000 Subject: [PATCH] Added a comment: Breaking change to "sync" --- ...5_b0f6d52ef7a94badd572c6cfa759efb3._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_15_b0f6d52ef7a94badd572c6cfa759efb3._comment diff --git a/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_15_b0f6d52ef7a94badd572c6cfa759efb3._comment b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_15_b0f6d52ef7a94badd572c6cfa759efb3._comment new file mode 100644 index 0000000000..8972a3b1b7 --- /dev/null +++ b/doc/todo/Having___39__git_annex_sync__39___optionally_add/comment_15_b0f6d52ef7a94badd572c6cfa759efb3._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="ewen" + avatar="http://cdn.libravatar.org/avatar/605b2981cb52b4af268455dee7a4f64e" + subject="Breaking change to "sync"" + date="2023-07-12T10:21:03Z" + content=""" +Via a comment on [my bug about the new `sync` warning suddenly appearing in 10.20230626](https://git-annex.branchable.com/bugs/Changing_sync_to_include_content_breaks_UX/?updated) I see that this fairly hidden discussion seems to have been the rationale for completely changing what \"sync\" does \"because some users expect it to do everything\". + +At the beginning of the design I might have agreed with you about \"what the sync command should do\" (and having another, eg, \"metasync\" command for the smaller version). But changing a fundamental command, a decade later, to do something different, based entirely on a \"wouldn't it have been nice (for some use cases) if...\" seems quite a stretch. + +As per the other bug, if you want to implement new behaviour for such a fundamental command (\"git annex sync\" is something one runs pretty constantly if using git annex actively from the command line) then it'd be best to implement it in another command name, instead of dramatically changing an existing one. (The other thread has a few more suggestions; I personally still like \"fullsync\" for the expanded version.) + +Either way, such a major -- behaviour breaking -- change needs to be much better documented than \"discussion in a bug that a few people saw\", and a note in passing in a changelog (which people have to find by noticing strange new output in probably scripted git annex usage). + +Ewen + +PS: I too think it's a terrible idea to have git annex default to auto-adding any files it can find. Maybe that makes some \"Dropbox-like\" use cases nicer, but it also entirely breaks other long standing use cases. +"""]]