change sync content transition plan and fine tune warning

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

View file

@ -256,8 +256,6 @@ instance DeferredParseClass SyncOptions where
seek :: SyncOptions -> CommandSeek
seek o = do
warnSyncContentTransition o
prepMerge
seek' o
@ -267,6 +265,7 @@ seek' o = startConcurrency transferStages $ do
let withbranch a = a =<< getCurrentBranch
remotes <- syncRemotes (syncWith o)
warnSyncContentTransition o remotes
-- Remotes that are git repositories, not (necesarily) special remotes.
let gitremotes = filter (Remote.gitSyncableRemoteType . Remote.remotetype) remotes
-- Remotes that contain annex object content.
@ -1102,23 +1101,28 @@ shouldSyncContent o
HasGitConfig (Just c) -> return c
_ -> return d
-- Transition started May 2023, should wait until that has been in a Debian
-- stable release before completing the transition.
warnSyncContentTransition :: SyncOptions -> Annex ()
warnSyncContentTransition o
-- See doc/todo/finish_sync_content_transition.mdwn
warnSyncContentTransition :: SyncOptions -> [Remote] -> Annex ()
warnSyncContentTransition o remotes
| operationMode o /= SyncMode = noop
| isJust (noContentOption o) || isJust (contentOption o) = noop
| not (null (contentOfOption o)) = noop
| otherwise = getGitConfigVal' annexSyncContent >>= \case
HasGlobalConfig (Just _) -> noop
HasGitConfig (Just _) -> noop
_ -> showwarning
_ -> do
m <- preferredContentMap
hereu <- getUUID
when (any (`M.member` m) (hereu:map Remote.uuid remotes)) $
showwarning
where
showwarning = earlyWarning $
"git-annex sync will change default behavior to operate on"
<> " --content in a future version of git-annex. Recommend"
<> " you explicitly use --no-content (or -g) to prepare for"
<> " that change. (Or you can configure annex.synccontent)"
"git-annex sync will change default behavior in the future to"
<> " send content to repositories that have"
<> " preferred content configured. If you do not want this to"
<> " send any content, use --no-content (or -g)"
<> " to prepare for that change."
<> " (Or you can configure annex.synccontent)"
notOnlyAnnex :: SyncOptions -> Annex Bool
notOnlyAnnex o = not <$> onlyAnnex o

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]]

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

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

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.

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.