mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

change sync content transition plan and fine tune warning

Browse source 
Only display warning when git-annex sync (without --content or
--no-content) is used with repositories that have preferred content
configured.

Sponsored-by: Leon Schuermann on Patreon
This commit is contained in:
Joey Hess 2023-08-14 13:51:35 -04:00
parent afb7703c9f
commit d467c70ef7
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 53 additions and 18 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/bugs/Changing_sync_to_include_content_breaks_UX.mdwn
View file

@ -64,3 +64,5 @@ Absolutely. I've been using git-annex since nearly the beginning; and use it ex
Thanks for writing git-annex. It's the reason I've been sponsoring you on Patreon for years.
Please don't break backwards compatibility. Even in the user experience :-)
> [[closing|done]] per new plan --[[Joey]]

21
doc/bugs/Changing_sync_to_include_content_breaks_UX/comment_19_bdc211b026d3b05de127f6ed5a3d19b0._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="joey"
subject="""comment 19"""
date="2023-08-14T16:56:48Z"
content="""
Changing the default preferred content expression to `present` rather than
`anything` would affect other things like `get --auto` and the assistant. I
don't think that is a good idea.
My idea in comment #15 is a special case for sync and not a wider change.
It will have a special case either way. The current special case means
that users who have set preferred content need to remember to use `sync
--content`. The new special case will only manifest as a difference in
behavior between `sync` and `sync --content` (and `get --auto` etc)
for users with no preferred content configured.
I do think that's a valuable narrowing of the special case.
Gone ahead and changed the warning.
"""]]

1
doc/git-annex-sync.mdwn
View file

@ -16,6 +16,7 @@ previously been added to the repository. Then it does the equivilant of
However, unlike those commands, this command does not transfer annexed
content by default. That will change in a future version of git-annex,
when syncing with repositories that have preferred content configured.
# OPTIONS

14
doc/todo/finish_sync_content_transition.mdwn Normal file
View file

@ -0,0 +1,14 @@
This transition is from `git-annex sync` needing `--content` to send
content to repositories that have preferred content configured, to sending
content by default to such repositories.
There should be no change in behavior with repositories that don't have
preferred content configured. `sync` without `--content` won't populate them
since that would be a surprising thing and a warning based transition was
judged by the community to be not sufficient to avoid that possible large
surprise. (See [[bugs/Changing_sync_to_include_content_breaks_UX]])
A warning was added in August 2023 when it's run in a way that will change
behavior. It would be good to wait until all git-annex users have gotten
the version with the warning, and used it for a while, before finishing the
transition.

7
doc/todo/v11_changes.mdwn
View file

@ -10,10 +10,3 @@ version.
after upgrading to the repo version that enables this. Depending on the
timing of v11, this may need to be put in a v12 upgrade that is delayed
some amount of time (eg 1 year) after v11.
* Finish the transition of git-annex sync defaulting to --content.
A warning was added in May 2023 when it's run in a way that will change
behavior. It would be good to wait until all git-annex users have
gotten the version with the warning, and used it for a while,
before finishing the transition. This does not need to be tied to a
repository version change really, but it would be reasonable to do so.