From b6c5b471b0dcab3e85ca75acedf007cbf6cbb172 Mon Sep 17 00:00:00 2001 From: jkniiv Date: Wed, 12 Jul 2023 16:25:49 +0000 Subject: [PATCH] Added a comment --- ..._ec80bdff87c7b70e4235cd5b2ba6ed05._comment | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment diff --git a/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment new file mode 100644 index 0000000000..65d31dd535 --- /dev/null +++ b/doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment @@ -0,0 +1,51 @@ +[[!comment format=mdwn + username="jkniiv" + avatar="http://cdn.libravatar.org/avatar/05fd8b33af7183342153e8013aa3713d" + subject="comment 10" + date="2023-07-12T16:25:48Z" + content=""" +@nobodyinperson, @ewen: Thank you for a balanced discussion! I'm not as elegant with words +but here is my take on your ideas. + +@nobodyinperson: + +> How about: + +> - `git annex assist` (exists, works): + +Yes, I understand the need for `assist` -- not in any way opposed to it. However, I think both +`assist` and `sync` ought learn a new option called `--edit` (or, `--edit-message` but that's wordy) +to be used in a similar fashion to `git commit -m msg --edit`, ie. it would open the user's preferred editor +to edit the commit message. + +> - `git annex metasync` (new proposal): + +You mention that this command would be \"Option-wise as 'dumb' as git annex assist\" but I disagree: as a true +replacement for `sync` it definitely should have at least the `--no-commit` flag as an additional option so that those +used to a `git annex add; git commit -m foo [--edit]; git annex sync --no-content --no-commit` workflow could +migrate to it. Also, no auto-adding (please!) if this is supposed be a replacement for `sync --no-content`. + +> - `git annex sync` (exists, has many options and configs): + +You mention that this command ought to be \"deprecated eventually (in many years), with a big warning upon execution now already\". +Yes, I agree but only if we get a `metasync` with a `--no-commit` flag for reasons above. + +--- + +@ewen: + +> 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.) + +I think you have a point there that the situation pre-10.20230626 would be preferable. +But I can live with Yann's (@nobodyinperson) suggestions if there is some amount of compromising. + +> 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) + +Yes, a replacement for `sync` should not in any case auto-add files. We want more control, not less. + +(continued...) +"""]] -- 2.30.2