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:
parent
afb7703c9f
commit
d467c70ef7
6 changed files with 53 additions and 18 deletions
|
@ -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
|
||||
|
|
|
@ -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]]
|
||||
|
|
|
@ -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.
|
||||
"""]]
|
|
@ -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
14
doc/todo/finish_sync_content_transition.mdwn
Normal 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.
|
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue