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 16:25:49 +00:00 • committed by admin
parent 4ed5cfa812
commit b6c5b471b0
1 changed files with 51 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

51
doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_10_ec80bdff87c7b70e4235cd5b2ba6ed05._comment Normal file
View file

@ -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...)
"""]]