2011-12-10 00:27:22 +00:00
|
|
|
{- git-annex command
|
|
|
|
-
|
2011-12-30 20:24:30 +00:00
|
|
|
- Copyright 2011 Joachim Breitner <mail@joachim-breitner.de>
|
2023-02-08 19:37:28 +00:00
|
|
|
- Copyright 2011-2023 Joey Hess <id@joeyh.name>
|
2011-12-10 00:27:22 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2011-12-10 00:27:22 +00:00
|
|
|
-}
|
|
|
|
|
2019-03-01 20:08:18 +00:00
|
|
|
{-# LANGUAGE FlexibleContexts #-}
|
2019-12-04 17:15:34 +00:00
|
|
|
{-# LANGUAGE OverloadedStrings #-}
|
2019-03-01 20:08:18 +00:00
|
|
|
|
2014-12-29 17:41:03 +00:00
|
|
|
module Command.Sync (
|
|
|
|
cmd,
|
2016-02-29 19:23:08 +00:00
|
|
|
CurrBranch,
|
2016-04-22 18:35:48 +00:00
|
|
|
mergeConfig,
|
2016-02-29 19:57:47 +00:00
|
|
|
merge,
|
2014-12-29 17:41:03 +00:00
|
|
|
prepMerge,
|
|
|
|
mergeLocal,
|
|
|
|
mergeRemote,
|
|
|
|
commitStaged,
|
2015-02-11 17:33:55 +00:00
|
|
|
commitMsg,
|
2014-12-29 17:41:03 +00:00
|
|
|
pushBranch,
|
|
|
|
updateBranch,
|
2018-10-20 18:12:04 +00:00
|
|
|
updateBranches,
|
2017-09-20 18:37:20 +00:00
|
|
|
seekExportContent,
|
2021-07-19 16:08:24 +00:00
|
|
|
parseUnrelatedHistoriesOption,
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
SyncOptions(..),
|
2014-12-29 17:41:03 +00:00
|
|
|
) where
|
2011-12-10 00:27:22 +00:00
|
|
|
|
|
|
|
import Command
|
2011-12-31 01:17:36 +00:00
|
|
|
import qualified Annex
|
2011-12-10 00:27:22 +00:00
|
|
|
import qualified Annex.Branch
|
2014-01-19 21:35:36 +00:00
|
|
|
import qualified Remote
|
|
|
|
import qualified Types.Remote as Remote
|
2014-03-02 22:01:07 +00:00
|
|
|
import Annex.Hook
|
2011-12-14 19:56:11 +00:00
|
|
|
import qualified Git.Command
|
2012-06-27 17:08:32 +00:00
|
|
|
import qualified Git.LsFiles as LsFiles
|
2011-12-30 22:04:01 +00:00
|
|
|
import qualified Git.Branch
|
2016-04-22 18:26:44 +00:00
|
|
|
import qualified Git.Merge
|
2015-01-07 02:23:04 +00:00
|
|
|
import qualified Git.Types as Git
|
2011-12-15 22:11:42 +00:00
|
|
|
import qualified Git.Ref
|
|
|
|
import qualified Git
|
2019-03-09 17:57:49 +00:00
|
|
|
import Git.FilePath
|
2011-12-31 07:27:37 +00:00
|
|
|
import qualified Remote.Git
|
2012-10-11 22:39:21 +00:00
|
|
|
import Config
|
2017-02-03 17:40:14 +00:00
|
|
|
import Config.GitConfig
|
2020-01-14 16:35:08 +00:00
|
|
|
import Annex.SpecialRemote.Config
|
2017-08-17 16:26:14 +00:00
|
|
|
import Config.DynamicConfig
|
2020-03-30 20:03:44 +00:00
|
|
|
import Annex.Path
|
2014-01-19 21:35:36 +00:00
|
|
|
import Annex.Wanted
|
|
|
|
import Annex.Content
|
2022-10-26 17:58:20 +00:00
|
|
|
import Annex.WorkTree
|
Do verification of checksums of annex objects downloaded from remotes.
* When annex objects are received into git repositories, their checksums are
verified then too.
* To get the old, faster, behavior of not verifying checksums, set
annex.verify=false, or remote.<name>.annex-verify=false.
* setkey, rekey: These commands also now verify that the provided file
matches the key, unless annex.verify=false.
* reinject: Already verified content; this can now be disabled by
setting annex.verify=false.
recvkey and reinject already did verification, so removed now duplicate
code from them. fsck still does its own verification, which is ok since it
does not use getViaTmp, so verification doesn't happen twice when using fsck
--from.
2015-10-01 19:54:37 +00:00
|
|
|
import Command.Get (getKey')
|
2014-02-02 23:57:22 +00:00
|
|
|
import qualified Command.Move
|
2017-09-19 18:20:47 +00:00
|
|
|
import qualified Command.Export
|
2019-03-09 17:21:49 +00:00
|
|
|
import qualified Command.Import
|
2014-01-19 21:35:36 +00:00
|
|
|
import Annex.Drop
|
2014-02-03 02:46:55 +00:00
|
|
|
import Annex.UUID
|
2015-02-11 17:33:55 +00:00
|
|
|
import Logs.UUID
|
2017-09-19 18:20:47 +00:00
|
|
|
import Logs.Export
|
2020-09-24 19:12:09 +00:00
|
|
|
import Logs.PreferredContent
|
2023-02-08 19:37:28 +00:00
|
|
|
import Logs.View
|
2014-03-04 20:26:15 +00:00
|
|
|
import Annex.AutoMerge
|
2016-02-29 19:23:08 +00:00
|
|
|
import Annex.AdjustedBranch
|
2020-11-16 18:09:55 +00:00
|
|
|
import Annex.AdjustedBranch.Merge
|
2023-02-08 19:37:28 +00:00
|
|
|
import Annex.View
|
2014-04-12 19:59:34 +00:00
|
|
|
import Annex.Ssh
|
2015-06-16 22:38:12 +00:00
|
|
|
import Annex.BloomFilter
|
2017-02-17 19:21:39 +00:00
|
|
|
import Annex.UpdateInstead
|
2017-09-19 18:20:47 +00:00
|
|
|
import Annex.Export
|
2017-09-28 18:14:07 +00:00
|
|
|
import Annex.TaggedPush
|
2018-10-19 19:17:48 +00:00
|
|
|
import Annex.CurrentBranch
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
import Annex.Import
|
2020-09-30 14:41:59 +00:00
|
|
|
import Annex.CheckIgnore
|
2020-09-24 19:12:09 +00:00
|
|
|
import Types.FileMatcher
|
2017-09-19 18:20:47 +00:00
|
|
|
import qualified Database.Export as Export
|
2015-06-16 21:58:15 +00:00
|
|
|
import Utility.Bloom
|
2015-08-20 21:18:21 +00:00
|
|
|
import Utility.OptParse
|
2017-12-31 20:08:31 +00:00
|
|
|
import Utility.Process.Transcript
|
2020-07-13 19:02:52 +00:00
|
|
|
import Utility.Tuple
|
2011-12-10 00:27:22 +00:00
|
|
|
|
2013-10-17 17:34:27 +00:00
|
|
|
import Control.Concurrent.MVar
|
2015-02-11 17:33:55 +00:00
|
|
|
import qualified Data.Map as M
|
2020-04-07 21:41:09 +00:00
|
|
|
import qualified Data.ByteString as S
|
|
|
|
import Data.Char
|
2011-12-10 00:27:22 +00:00
|
|
|
|
2015-07-08 16:33:27 +00:00
|
|
|
cmd :: Command
|
2022-06-29 17:28:08 +00:00
|
|
|
cmd = withAnnexOptions [jobsOption, backendOption] $
|
2015-08-14 17:49:55 +00:00
|
|
|
command "sync" SectionCommon
|
|
|
|
"synchronize local repository with remotes"
|
2017-03-20 20:00:06 +00:00
|
|
|
(paramRepeating paramRemote) (seek <--< optParser)
|
2015-07-09 23:03:21 +00:00
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
data SyncOptions = SyncOptions
|
2015-07-09 23:03:21 +00:00
|
|
|
{ syncWith :: CmdParams
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
, onlyAnnexOption :: Bool
|
|
|
|
, notOnlyAnnexOption :: Bool
|
2015-09-13 17:15:35 +00:00
|
|
|
, commitOption :: Bool
|
2017-02-03 18:36:14 +00:00
|
|
|
, noCommitOption :: Bool
|
2015-07-09 23:03:21 +00:00
|
|
|
, messageOption :: Maybe String
|
2015-09-13 17:15:35 +00:00
|
|
|
, pullOption :: Bool
|
|
|
|
, pushOption :: Bool
|
|
|
|
, contentOption :: Bool
|
2017-02-03 18:31:17 +00:00
|
|
|
, noContentOption :: Bool
|
2017-03-20 20:00:06 +00:00
|
|
|
, contentOfOption :: [FilePath]
|
2017-09-28 18:14:07 +00:00
|
|
|
, cleanupOption :: Bool
|
2015-07-09 23:03:21 +00:00
|
|
|
, keyOptions :: Maybe KeyOptions
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
, resolveMergeOverride :: Bool
|
2021-07-19 16:08:24 +00:00
|
|
|
, allowUnrelatedHistories :: Bool
|
2015-07-09 23:03:21 +00:00
|
|
|
}
|
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
instance Default SyncOptions where
|
|
|
|
def = SyncOptions
|
|
|
|
{ syncWith = []
|
|
|
|
, onlyAnnexOption = False
|
|
|
|
, notOnlyAnnexOption = False
|
|
|
|
, commitOption = False
|
|
|
|
, noCommitOption = False
|
|
|
|
, messageOption = Nothing
|
|
|
|
, pullOption = False
|
|
|
|
, pushOption = False
|
|
|
|
, contentOption = False
|
|
|
|
, noContentOption = False
|
|
|
|
, contentOfOption = []
|
|
|
|
, cleanupOption = False
|
|
|
|
, keyOptions = Nothing
|
|
|
|
, resolveMergeOverride = False
|
2021-07-19 16:08:24 +00:00
|
|
|
, allowUnrelatedHistories = False
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
}
|
2017-06-01 16:46:36 +00:00
|
|
|
|
2015-07-09 23:03:21 +00:00
|
|
|
optParser :: CmdParamsDesc -> Parser SyncOptions
|
|
|
|
optParser desc = SyncOptions
|
2015-09-14 17:19:04 +00:00
|
|
|
<$> (many $ argument str
|
|
|
|
( metavar desc
|
|
|
|
<> completeRemotes
|
|
|
|
))
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
<*> switch
|
|
|
|
( long "only-annex"
|
|
|
|
<> short 'a'
|
|
|
|
<> help "only sync git-annex branch and annexed file contents"
|
|
|
|
)
|
|
|
|
<*> switch
|
|
|
|
( long "not-only-annex"
|
|
|
|
<> help "sync git branches as well as annex"
|
|
|
|
)
|
2017-02-03 18:36:14 +00:00
|
|
|
<*> switch
|
|
|
|
( long "commit"
|
|
|
|
<> help "commit changes to git"
|
|
|
|
)
|
|
|
|
<*> switch
|
|
|
|
( long "no-commit"
|
|
|
|
<> help "avoid git commit"
|
2015-07-09 23:03:21 +00:00
|
|
|
)
|
|
|
|
<*> optional (strOption
|
|
|
|
( long "message" <> short 'm' <> metavar "MSG"
|
|
|
|
<> help "commit message"
|
|
|
|
))
|
2015-09-13 17:15:35 +00:00
|
|
|
<*> invertableSwitch "pull" True
|
|
|
|
( help "avoid git pulls from remotes"
|
|
|
|
)
|
|
|
|
<*> invertableSwitch "push" True
|
|
|
|
( help "avoid git pushes to remotes"
|
|
|
|
)
|
2017-02-03 18:31:17 +00:00
|
|
|
<*> switch
|
|
|
|
( long "content"
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
<> help "transfer annexed file contents"
|
2017-02-03 18:31:17 +00:00
|
|
|
)
|
|
|
|
<*> switch
|
|
|
|
( long "no-content"
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
<> help "do not transfer annexed file contents"
|
2015-09-13 17:15:35 +00:00
|
|
|
)
|
2017-03-20 20:00:06 +00:00
|
|
|
<*> many (strOption
|
|
|
|
( long "content-of"
|
|
|
|
<> short 'C'
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
<> help "transfer contents of annexed files in a given location"
|
2017-03-20 20:00:06 +00:00
|
|
|
<> metavar paramPath
|
|
|
|
))
|
2017-09-28 18:14:07 +00:00
|
|
|
<*> switch
|
|
|
|
( long "cleanup"
|
|
|
|
<> help "remove synced/ branches from previous sync"
|
|
|
|
)
|
2015-07-09 23:03:21 +00:00
|
|
|
<*> optional parseAllOption
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
<*> invertableSwitch "resolvemerge" True
|
2017-06-01 16:46:36 +00:00
|
|
|
( help "do not automatically resolve merge conflicts"
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
)
|
2021-07-19 16:08:24 +00:00
|
|
|
<*> parseUnrelatedHistoriesOption
|
|
|
|
|
|
|
|
parseUnrelatedHistoriesOption :: Parser Bool
|
|
|
|
parseUnrelatedHistoriesOption =
|
|
|
|
invertableSwitch "allow-unrelated-histories" False
|
|
|
|
( help "allow merging unrelated histories"
|
|
|
|
)
|
2015-07-09 23:03:21 +00:00
|
|
|
|
2017-03-20 20:00:06 +00:00
|
|
|
-- Since prepMerge changes the working directory, FilePath options
|
|
|
|
-- have to be adjusted.
|
|
|
|
instance DeferredParseClass SyncOptions where
|
|
|
|
finishParse v = SyncOptions
|
|
|
|
<$> pure (syncWith v)
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
<*> pure (onlyAnnexOption v)
|
|
|
|
<*> pure (notOnlyAnnexOption v)
|
2017-03-20 20:00:06 +00:00
|
|
|
<*> pure (commitOption v)
|
|
|
|
<*> pure (noCommitOption v)
|
|
|
|
<*> pure (messageOption v)
|
|
|
|
<*> pure (pullOption v)
|
|
|
|
<*> pure (pushOption v)
|
|
|
|
<*> pure (contentOption v)
|
|
|
|
<*> pure (noContentOption v)
|
2020-11-04 18:20:37 +00:00
|
|
|
<*> liftIO (mapM (fromRawFilePath <$$> absPath . toRawFilePath) (contentOfOption v))
|
2017-09-28 18:14:07 +00:00
|
|
|
<*> pure (cleanupOption v)
|
2017-03-20 20:00:06 +00:00
|
|
|
<*> pure (keyOptions v)
|
2017-06-01 16:46:36 +00:00
|
|
|
<*> pure (resolveMergeOverride v)
|
2021-07-19 16:08:24 +00:00
|
|
|
<*> pure (allowUnrelatedHistories v)
|
2017-03-20 20:00:06 +00:00
|
|
|
|
2015-07-09 23:03:21 +00:00
|
|
|
seek :: SyncOptions -> CommandSeek
|
2019-06-19 16:35:08 +00:00
|
|
|
seek o = do
|
2013-09-13 18:55:55 +00:00
|
|
|
prepMerge
|
2023-01-24 17:45:01 +00:00
|
|
|
startConcurrency transferStages (seek' o)
|
2019-06-19 16:35:08 +00:00
|
|
|
|
|
|
|
seek' :: SyncOptions -> CommandSeek
|
|
|
|
seek' o = do
|
2018-10-19 19:17:48 +00:00
|
|
|
let withbranch a = a =<< getCurrentBranch
|
2013-10-17 17:34:27 +00:00
|
|
|
|
2015-07-09 23:03:21 +00:00
|
|
|
remotes <- syncRemotes (syncWith o)
|
2020-12-23 16:10:39 +00:00
|
|
|
-- Remotes that are git repositories, not special remotes.
|
2020-02-19 17:58:26 +00:00
|
|
|
let gitremotes = filter (Remote.gitSyncableRemoteType . Remote.remotetype) remotes
|
2020-12-23 16:10:39 +00:00
|
|
|
-- Remotes that contain annex object content.
|
|
|
|
contentremotes <- filter (\r -> Remote.uuid r /= NoUUID)
|
2017-08-17 16:26:14 +00:00
|
|
|
<$> filterM (not <$$> liftIO . getDynamicConfig . remoteAnnexIgnore . Remote.gitconfig) remotes
|
2014-01-19 21:35:36 +00:00
|
|
|
|
2017-09-28 18:14:07 +00:00
|
|
|
if cleanupOption o
|
|
|
|
then do
|
|
|
|
commandAction (withbranch cleanupLocal)
|
|
|
|
mapM_ (commandAction . withbranch . cleanupRemote) gitremotes
|
|
|
|
else do
|
2021-07-19 16:08:24 +00:00
|
|
|
mc <- mergeConfig (allowUnrelatedHistories o)
|
2021-07-19 15:28:31 +00:00
|
|
|
|
2017-09-28 18:14:07 +00:00
|
|
|
-- Syncing involves many actions, any of which
|
|
|
|
-- can independently fail, without preventing
|
|
|
|
-- the others from running.
|
|
|
|
-- These actions cannot be run concurrently.
|
2017-09-19 18:20:47 +00:00
|
|
|
mapM_ includeCommandAction $ concat
|
2017-09-28 18:14:07 +00:00
|
|
|
[ [ commit o ]
|
2021-07-19 15:28:31 +00:00
|
|
|
, [ withbranch (mergeLocal mc o) ]
|
|
|
|
, map (withbranch . pullRemote o mc) gitremotes
|
2017-09-28 18:14:07 +00:00
|
|
|
, [ mergeAnnex ]
|
2017-09-19 18:20:47 +00:00
|
|
|
]
|
2019-03-09 17:57:49 +00:00
|
|
|
|
2020-09-28 19:03:15 +00:00
|
|
|
content <- shouldSyncContent o
|
|
|
|
|
2020-12-23 16:10:39 +00:00
|
|
|
forM_ (filter isImport contentremotes) $
|
remove direct mode remnant of merging unrelated histories
sync, merge, post-receive: Avoid merging unrelated histories, which used to
be allowed only to support direct mode repositories.
(However, sync does still merge unrelated histories when importing trees
from special remotes, and the assistant still merges unrelated histories
always.)
See 556b2ded2ba8270846fa207255b4c2def6ef5d8a for why this was added
back in 2016, for direct mode.
This is a behavior change, which might break something that was relying
on sync merging unrelated histories, but git had a good reason to
prevent it, since it's easy to foot shoot with it, and git-annex should
follow suit.
Sponsored-by: Noam Kremen on Patreon
2021-07-19 15:40:48 +00:00
|
|
|
withbranch . importRemote content o
|
2020-12-23 16:10:39 +00:00
|
|
|
forM_ (filter isThirdPartyPopulated contentremotes) $
|
|
|
|
pullThirdPartyPopulated o
|
2020-09-28 19:03:15 +00:00
|
|
|
|
|
|
|
when content $ do
|
2019-03-09 17:57:49 +00:00
|
|
|
-- Send content to any exports before other
|
|
|
|
-- repositories, in case that lets content
|
|
|
|
-- be dropped from other repositories.
|
2019-03-09 17:21:49 +00:00
|
|
|
exportedcontent <- withbranch $
|
2020-12-23 16:10:39 +00:00
|
|
|
seekExportContent (Just o)
|
|
|
|
(filter isExport contentremotes)
|
|
|
|
|
|
|
|
-- Sync content with remotes, but not with
|
|
|
|
-- export or import remotes, which handle content
|
|
|
|
-- syncing as part of export and import.
|
2019-03-09 17:21:49 +00:00
|
|
|
syncedcontent <- withbranch $
|
2020-12-23 16:10:39 +00:00
|
|
|
seekSyncContent o $ filter
|
|
|
|
(\r -> not (isExport r || isImport r))
|
|
|
|
contentremotes
|
|
|
|
|
2017-09-28 18:14:07 +00:00
|
|
|
-- Transferring content can take a while,
|
|
|
|
-- and other changes can be pushed to the
|
|
|
|
-- git-annex branch on the remotes in the
|
|
|
|
-- meantime, so pull and merge again to
|
|
|
|
-- avoid our push overwriting those changes.
|
|
|
|
when (syncedcontent || exportedcontent) $ do
|
|
|
|
mapM_ includeCommandAction $ concat
|
2021-07-19 15:28:31 +00:00
|
|
|
[ map (withbranch . pullRemote o mc) gitremotes
|
2017-09-28 18:14:07 +00:00
|
|
|
, [ commitAnnex, mergeAnnex ]
|
|
|
|
]
|
2015-08-14 17:49:55 +00:00
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
void $ includeCommandAction $ withbranch $ pushLocal o
|
2017-09-28 18:14:07 +00:00
|
|
|
-- Pushes to remotes can run concurrently.
|
|
|
|
mapM_ (commandAction . withbranch . pushRemote o) gitremotes
|
2017-02-03 18:31:17 +00:00
|
|
|
|
2013-09-13 18:55:55 +00:00
|
|
|
{- Merging may delete the current directory, so go to the top
|
2014-01-19 21:35:36 +00:00
|
|
|
- of the repo. This also means that sync always acts on all files in the
|
|
|
|
- repository, not just on a subdirectory. -}
|
2013-09-13 18:55:55 +00:00
|
|
|
prepMerge :: Annex ()
|
2019-12-09 17:49:05 +00:00
|
|
|
prepMerge = Annex.changeDirectory . fromRawFilePath =<< fromRepo Git.repoPath
|
2013-09-13 18:55:55 +00:00
|
|
|
|
remove direct mode remnant of merging unrelated histories
sync, merge, post-receive: Avoid merging unrelated histories, which used to
be allowed only to support direct mode repositories.
(However, sync does still merge unrelated histories when importing trees
from special remotes, and the assistant still merges unrelated histories
always.)
See 556b2ded2ba8270846fa207255b4c2def6ef5d8a for why this was added
back in 2016, for direct mode.
This is a behavior change, which might break something that was relying
on sync merging unrelated histories, but git had a good reason to
prevent it, since it's easy to foot shoot with it, and git-annex should
follow suit.
Sponsored-by: Noam Kremen on Patreon
2021-07-19 15:40:48 +00:00
|
|
|
mergeConfig :: Bool -> Annex [Git.Merge.MergeConfig]
|
|
|
|
mergeConfig mergeunrelated = do
|
2021-07-19 15:28:31 +00:00
|
|
|
quiet <- commandProgressDisabled
|
|
|
|
return $ catMaybes
|
|
|
|
[ Just Git.Merge.MergeNonInteractive
|
remove direct mode remnant of merging unrelated histories
sync, merge, post-receive: Avoid merging unrelated histories, which used to
be allowed only to support direct mode repositories.
(However, sync does still merge unrelated histories when importing trees
from special remotes, and the assistant still merges unrelated histories
always.)
See 556b2ded2ba8270846fa207255b4c2def6ef5d8a for why this was added
back in 2016, for direct mode.
This is a behavior change, which might break something that was relying
on sync merging unrelated histories, but git had a good reason to
prevent it, since it's easy to foot shoot with it, and git-annex should
follow suit.
Sponsored-by: Noam Kremen on Patreon
2021-07-19 15:40:48 +00:00
|
|
|
, if mergeunrelated
|
|
|
|
then Just Git.Merge.MergeUnrelatedHistories
|
|
|
|
else Nothing
|
|
|
|
, if quiet
|
|
|
|
then Just Git.Merge.MergeQuiet
|
|
|
|
else Nothing
|
2021-07-19 15:28:31 +00:00
|
|
|
]
|
2016-04-22 18:35:48 +00:00
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
merge :: CurrBranch -> [Git.Merge.MergeConfig] -> SyncOptions -> Git.Branch.CommitMode -> Git.Branch -> Annex Bool
|
2020-09-07 17:26:16 +00:00
|
|
|
merge currbranch mergeconfig o commitmode tomerge = do
|
|
|
|
canresolvemerge <- if resolveMergeOverride o
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
then getGitConfigVal annexResolveMerge
|
|
|
|
else return False
|
2020-09-07 17:26:16 +00:00
|
|
|
case currbranch of
|
|
|
|
(Just b, Just adj) -> mergeToAdjustedBranch tomerge (b, adj) mergeconfig canresolvemerge commitmode
|
|
|
|
(b, _) -> autoMergeFrom tomerge b mergeconfig commitmode canresolvemerge
|
2016-02-29 19:57:47 +00:00
|
|
|
|
2016-03-03 18:13:54 +00:00
|
|
|
syncBranch :: Git.Branch -> Git.Branch
|
2023-02-08 17:55:55 +00:00
|
|
|
syncBranch = Git.Ref.underBase "refs/heads/synced" . origBranch
|
|
|
|
|
|
|
|
origBranch :: Git.Branch -> Git.Branch
|
|
|
|
origBranch = fromViewBranch . fromAdjustedBranch
|
2011-12-29 17:37:30 +00:00
|
|
|
|
2011-12-31 08:11:39 +00:00
|
|
|
remoteBranch :: Remote -> Git.Ref -> Git.Ref
|
work around lack of receive.denyCurrentBranch in direct mode
Now that direct mode sets core.bare=true, git's normal prohibition about
pushing into the currently checked out branch doesn't work.
A simple fix for this would be an update hook which blocks the pushes..
but git hooks must be executable, and git-annex needs to be usable on eg,
FAT, which lacks x bits.
Instead, enabling direct mode switches the branch (eg master) to a special
purpose branch (eg annex/direct/master). This branch is not pushed when
syncing; instead any changes that git annex sync commits get written to
master, and it's pushed (along with synced/master) to the remote.
Note that initialization has been changed to always call setDirect,
even if it's just setDirect False for indirect mode. This is needed because
if the user has just cloned a direct mode repo, that nothing has synced
with before, it may have no master branch, and only a annex/direct/master.
Resulting in that branch being checked out locally too. Calling setDirect False
for indirect mode moves back out of this branch, to a new master branch,
and ensures that a manual "git push" doesn't push changes directly to
the annex/direct/master of the remote. (It's possible that the user
makes a commit w/o using git-annex and pushes it, but nothing I can do
about that really.)
This commit was sponsored by Jonathan Harrington.
2013-11-06 01:08:31 +00:00
|
|
|
remoteBranch remote = Git.Ref.underBase $ "refs/remotes/" ++ Remote.name remote
|
2011-12-31 07:01:18 +00:00
|
|
|
|
2015-10-15 19:10:14 +00:00
|
|
|
-- Do automatic initialization of remotes when possible when getting remote
|
|
|
|
-- list.
|
2011-12-31 08:11:39 +00:00
|
|
|
syncRemotes :: [String] -> Annex [Remote]
|
2017-08-17 16:26:14 +00:00
|
|
|
syncRemotes ps = do
|
|
|
|
remotelist <- Remote.remoteList' True
|
2018-06-04 18:31:55 +00:00
|
|
|
available <- filterM (liftIO . getDynamicConfig . remoteAnnexSync . Remote.gitconfig) remotelist
|
2017-08-17 16:26:14 +00:00
|
|
|
syncRemotes' ps available
|
2015-08-05 17:49:54 +00:00
|
|
|
|
|
|
|
syncRemotes' :: [String] -> [Remote] -> Annex [Remote]
|
2017-08-17 16:26:14 +00:00
|
|
|
syncRemotes' ps available =
|
2022-06-28 19:28:14 +00:00
|
|
|
ifM (Annex.getRead Annex.fast) ( fastest <$> wanted , wanted )
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
|
|
|
wanted
|
2015-08-05 17:49:54 +00:00
|
|
|
| null ps = filterM good (concat $ Remote.byCost available)
|
2012-11-12 05:05:04 +00:00
|
|
|
| otherwise = listed
|
2014-12-29 17:41:03 +00:00
|
|
|
|
2015-08-05 17:49:54 +00:00
|
|
|
listed = concat <$> mapM Remote.byNameOrGroup ps
|
2014-12-29 17:41:03 +00:00
|
|
|
|
2014-01-19 21:35:36 +00:00
|
|
|
good r
|
2020-02-19 17:58:26 +00:00
|
|
|
| Remote.gitSyncableRemoteType (Remote.remotetype r) =
|
2018-06-04 18:31:55 +00:00
|
|
|
Remote.Git.repoAvail =<< Remote.getRepo r
|
2014-01-19 21:35:36 +00:00
|
|
|
| otherwise = return True
|
2014-12-29 17:41:03 +00:00
|
|
|
|
2012-11-12 05:05:04 +00:00
|
|
|
fastest = fromMaybe [] . headMaybe . Remote.byCost
|
2011-12-10 00:27:22 +00:00
|
|
|
|
2015-07-09 23:03:21 +00:00
|
|
|
commit :: SyncOptions -> CommandStart
|
2020-09-14 20:49:33 +00:00
|
|
|
commit o = stopUnless shouldcommit $ starting "commit" ai si $ do
|
2015-09-13 17:15:35 +00:00
|
|
|
commitmessage <- maybe commitMsg return (messageOption o)
|
2018-08-02 18:06:06 +00:00
|
|
|
Annex.Branch.commit =<< Annex.Branch.commitMessage
|
2019-08-26 19:52:19 +00:00
|
|
|
next $ do
|
|
|
|
showOutput
|
2021-07-19 15:28:31 +00:00
|
|
|
let cmode = Git.Branch.ManualCommit
|
|
|
|
cquiet <- Git.Branch.CommitQuiet <$> commandProgressDisabled
|
|
|
|
void $ inRepo $ Git.Branch.commitCommand cmode cquiet
|
2019-08-26 19:52:19 +00:00
|
|
|
[ Param "-a"
|
|
|
|
, Param "-m"
|
|
|
|
, Param commitmessage
|
|
|
|
]
|
|
|
|
return True
|
2015-07-07 20:36:11 +00:00
|
|
|
where
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
shouldcommit = notOnlyAnnex o <&&>
|
|
|
|
( pure (commitOption o)
|
2017-02-03 18:36:14 +00:00
|
|
|
<||> (pure (not (noCommitOption o)) <&&> getGitConfigVal annexAutoCommit)
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
)
|
2020-09-14 20:49:33 +00:00
|
|
|
ai = ActionItemOther Nothing
|
|
|
|
si = SeekInput []
|
2013-12-01 17:59:39 +00:00
|
|
|
|
2015-02-11 17:33:55 +00:00
|
|
|
commitMsg :: Annex String
|
|
|
|
commitMsg = do
|
|
|
|
u <- getUUID
|
2019-01-01 19:39:45 +00:00
|
|
|
m <- uuidDescMap
|
|
|
|
return $ "git-annex in " ++ maybe "unknown" fromUUIDDesc (M.lookup u m)
|
2015-02-11 17:33:55 +00:00
|
|
|
|
2014-07-04 15:36:59 +00:00
|
|
|
commitStaged :: Git.Branch.CommitMode -> String -> Annex Bool
|
2015-03-04 19:25:13 +00:00
|
|
|
commitStaged commitmode commitmessage = do
|
|
|
|
runAnnexHook preCommitAnnexHook
|
|
|
|
mb <- inRepo Git.Branch.currentUnsafe
|
|
|
|
let (getparent, branch) = case mb of
|
|
|
|
Just b -> (Git.Ref.sha b, b)
|
|
|
|
Nothing -> (Git.Ref.headSha, Git.Ref.headRef)
|
|
|
|
parents <- maybeToList <$> inRepo getparent
|
|
|
|
void $ inRepo $ Git.Branch.commit commitmode False commitmessage branch parents
|
|
|
|
return True
|
2011-12-10 16:21:22 +00:00
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
mergeLocal :: [Git.Merge.MergeConfig] -> SyncOptions -> CurrBranch -> CommandStart
|
|
|
|
mergeLocal mergeconfig o currbranch = stopUnless (notOnlyAnnex o) $
|
|
|
|
mergeLocal' mergeconfig o currbranch
|
|
|
|
|
|
|
|
mergeLocal' :: [Git.Merge.MergeConfig] -> SyncOptions -> CurrBranch -> CommandStart
|
2020-05-05 17:57:20 +00:00
|
|
|
mergeLocal' mergeconfig o currbranch@(Just branch, _) =
|
|
|
|
needMerge currbranch branch >>= \case
|
make CommandStart return a StartMessage
The goal is to be able to run CommandStart in the main thread when -J is
used, rather than unncessarily passing it off to a worker thread, which
incurs overhead that is signficant when the CommandStart is going to
quickly decide to stop.
To do that, the message it displays needs to be displayed in the worker
thread, after the CommandStart has run.
Also, the change will mean that CommandStart will no longer necessarily
run with the same Annex state as CommandPerform. While its docs already
said it should avoid modifying Annex state, I audited all the
CommandStart code as part of the conversion. (Note that CommandSeek
already sometimes runs with a different Annex state, and that has not been
a source of any problems, so I am not too worried that this change will
lead to breakage going forward.)
The only modification of Annex state I found was it calling
allowMessages in some Commands that default to noMessages. Dealt with
that by adding a startCustomOutput and a startingUsualMessages.
This lets a command start with noMessages and then select the output it
wants for each CommandStart.
One bit of breakage: onlyActionOn has been removed from commands that used it.
The plan is that, since a StartMessage contains an ActionItem,
when a Key can be extracted from that, the parallel job runner can
run onlyActionOn' automatically. Then commands won't need to worry about
this detail. Future work.
Otherwise, this was a fairly straightforward process of making each
CommandStart compile again. Hopefully other behavior changes were mostly
avoided.
In a few cases, a command had a CommandStart that called a CommandPerform
that then called showStart multiple times. I have collapsed those
down to a single start action. The main command to perhaps suffer from it
is Command.Direct, which used to show a start for each file, and no
longer does.
Another minor behavior change is that some commands used showStart
before, but had an associated file and a Key available, so were changed
to ShowStart with an ActionItemAssociatedFile. That will not change the
normal output or behavior, but --json output will now include the key.
This should not break it for anyone using a real json parser.
2019-06-06 19:42:30 +00:00
|
|
|
Nothing -> stop
|
2020-09-14 20:49:33 +00:00
|
|
|
Just syncbranch -> do
|
|
|
|
let ai = ActionItemOther (Just $ Git.Ref.describe syncbranch)
|
|
|
|
let si = SeekInput []
|
|
|
|
starting "merge" ai si $
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
next $ merge currbranch mergeconfig o Git.Branch.ManualCommit syncbranch
|
2020-05-05 17:57:20 +00:00
|
|
|
mergeLocal' _ _ currbranch@(Nothing, _) = inRepo Git.Branch.currentUnsafe >>= \case
|
|
|
|
Just branch -> needMerge currbranch branch >>= \case
|
make CommandStart return a StartMessage
The goal is to be able to run CommandStart in the main thread when -J is
used, rather than unncessarily passing it off to a worker thread, which
incurs overhead that is signficant when the CommandStart is going to
quickly decide to stop.
To do that, the message it displays needs to be displayed in the worker
thread, after the CommandStart has run.
Also, the change will mean that CommandStart will no longer necessarily
run with the same Annex state as CommandPerform. While its docs already
said it should avoid modifying Annex state, I audited all the
CommandStart code as part of the conversion. (Note that CommandSeek
already sometimes runs with a different Annex state, and that has not been
a source of any problems, so I am not too worried that this change will
lead to breakage going forward.)
The only modification of Annex state I found was it calling
allowMessages in some Commands that default to noMessages. Dealt with
that by adding a startCustomOutput and a startingUsualMessages.
This lets a command start with noMessages and then select the output it
wants for each CommandStart.
One bit of breakage: onlyActionOn has been removed from commands that used it.
The plan is that, since a StartMessage contains an ActionItem,
when a Key can be extracted from that, the parallel job runner can
run onlyActionOn' automatically. Then commands won't need to worry about
this detail. Future work.
Otherwise, this was a fairly straightforward process of making each
CommandStart compile again. Hopefully other behavior changes were mostly
avoided.
In a few cases, a command had a CommandStart that called a CommandPerform
that then called showStart multiple times. I have collapsed those
down to a single start action. The main command to perhaps suffer from it
is Command.Direct, which used to show a start for each file, and no
longer does.
Another minor behavior change is that some commands used showStart
before, but had an associated file and a Key available, so were changed
to ShowStart with an ActionItemAssociatedFile. That will not change the
normal output or behavior, but --json output will now include the key.
This should not break it for anyone using a real json parser.
2019-06-06 19:42:30 +00:00
|
|
|
Nothing -> stop
|
2020-09-14 20:49:33 +00:00
|
|
|
Just syncbranch -> do
|
|
|
|
let ai = ActionItemOther (Just $ Git.Ref.describe syncbranch)
|
|
|
|
let si = SeekInput []
|
|
|
|
starting "merge" ai si $ do
|
2020-05-05 17:57:20 +00:00
|
|
|
warning $ "There are no commits yet to branch " ++ Git.fromRef branch ++ ", so cannot merge " ++ Git.fromRef syncbranch ++ " into it."
|
make CommandStart return a StartMessage
The goal is to be able to run CommandStart in the main thread when -J is
used, rather than unncessarily passing it off to a worker thread, which
incurs overhead that is signficant when the CommandStart is going to
quickly decide to stop.
To do that, the message it displays needs to be displayed in the worker
thread, after the CommandStart has run.
Also, the change will mean that CommandStart will no longer necessarily
run with the same Annex state as CommandPerform. While its docs already
said it should avoid modifying Annex state, I audited all the
CommandStart code as part of the conversion. (Note that CommandSeek
already sometimes runs with a different Annex state, and that has not been
a source of any problems, so I am not too worried that this change will
lead to breakage going forward.)
The only modification of Annex state I found was it calling
allowMessages in some Commands that default to noMessages. Dealt with
that by adding a startCustomOutput and a startingUsualMessages.
This lets a command start with noMessages and then select the output it
wants for each CommandStart.
One bit of breakage: onlyActionOn has been removed from commands that used it.
The plan is that, since a StartMessage contains an ActionItem,
when a Key can be extracted from that, the parallel job runner can
run onlyActionOn' automatically. Then commands won't need to worry about
this detail. Future work.
Otherwise, this was a fairly straightforward process of making each
CommandStart compile again. Hopefully other behavior changes were mostly
avoided.
In a few cases, a command had a CommandStart that called a CommandPerform
that then called showStart multiple times. I have collapsed those
down to a single start action. The main command to perhaps suffer from it
is Command.Direct, which used to show a start for each file, and no
longer does.
Another minor behavior change is that some commands used showStart
before, but had an associated file and a Key available, so were changed
to ShowStart with an ActionItemAssociatedFile. That will not change the
normal output or behavior, but --json output will now include the key.
This should not break it for anyone using a real json parser.
2019-06-06 19:42:30 +00:00
|
|
|
next $ return False
|
2020-05-05 17:57:20 +00:00
|
|
|
Nothing -> stop
|
2017-02-14 19:58:05 +00:00
|
|
|
|
|
|
|
-- Returns the branch that should be merged, if any.
|
2020-05-05 17:57:20 +00:00
|
|
|
needMerge :: CurrBranch -> Git.Branch -> Annex (Maybe Git.Branch)
|
|
|
|
needMerge currbranch headbranch = ifM (allM id checks)
|
2017-02-14 19:58:05 +00:00
|
|
|
( return (Just syncbranch)
|
|
|
|
, return Nothing
|
|
|
|
)
|
|
|
|
where
|
2020-05-05 17:57:20 +00:00
|
|
|
syncbranch = syncBranch headbranch
|
|
|
|
checks = case currbranch of
|
|
|
|
(Just _, madj) ->
|
|
|
|
let branch' = maybe headbranch (adjBranch . originalToAdjusted headbranch) madj
|
|
|
|
in
|
|
|
|
[ not <$> isBareRepo
|
|
|
|
, inRepo (Git.Ref.exists syncbranch)
|
|
|
|
, inRepo (Git.Branch.changed branch' syncbranch)
|
|
|
|
]
|
|
|
|
(Nothing, _) ->
|
|
|
|
[ not <$> isBareRepo
|
|
|
|
, inRepo (Git.Ref.exists syncbranch)
|
|
|
|
]
|
2011-12-29 17:37:30 +00:00
|
|
|
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
pushLocal :: SyncOptions -> CurrBranch -> CommandStart
|
|
|
|
pushLocal o b = stopUnless (notOnlyAnnex o) $ do
|
2018-10-20 18:12:04 +00:00
|
|
|
updateBranches b
|
2014-06-16 15:32:13 +00:00
|
|
|
stop
|
|
|
|
|
2018-10-20 18:12:04 +00:00
|
|
|
updateBranches :: CurrBranch -> Annex ()
|
|
|
|
updateBranches (Nothing, _) = noop
|
|
|
|
updateBranches (Just branch, madj) = do
|
2016-03-31 22:54:35 +00:00
|
|
|
-- When in an adjusted branch, propigate any changes made to it
|
2018-10-20 18:12:04 +00:00
|
|
|
-- back to the original branch. The adjusted branch may also need
|
2020-11-16 19:13:48 +00:00
|
|
|
-- to be updated, if the adjustment is not stable, and the usual
|
|
|
|
-- configuration does not update it.
|
2018-10-20 18:12:04 +00:00
|
|
|
case madj of
|
|
|
|
Just adj -> do
|
|
|
|
let origbranch = branch
|
|
|
|
propigateAdjustedCommits origbranch adj
|
2020-11-16 19:13:48 +00:00
|
|
|
unless (adjustmentIsStable adj) $
|
|
|
|
annexAdjustedBranchRefresh <$> Annex.getGitConfig >>= \case
|
|
|
|
0 -> adjustedBranchRefreshFull adj origbranch
|
|
|
|
_ -> return ()
|
2023-02-08 19:37:28 +00:00
|
|
|
-- When in a view branch, update it to reflect any changes
|
|
|
|
-- of its parent branch or the metadata.
|
|
|
|
Nothing -> currentView >>= \case
|
|
|
|
Nothing -> noop
|
|
|
|
Just view -> updateView view >>= \case
|
|
|
|
Nothing -> noop
|
|
|
|
Just newcommit -> do
|
|
|
|
ok <- inRepo $ Git.Command.runBool
|
|
|
|
[ Param "merge"
|
|
|
|
, Param (Git.fromRef newcommit)
|
|
|
|
]
|
|
|
|
unless ok $
|
|
|
|
giveup $ "failed to update view"
|
2018-10-20 18:12:04 +00:00
|
|
|
|
work around lack of receive.denyCurrentBranch in direct mode
Now that direct mode sets core.bare=true, git's normal prohibition about
pushing into the currently checked out branch doesn't work.
A simple fix for this would be an update hook which blocks the pushes..
but git hooks must be executable, and git-annex needs to be usable on eg,
FAT, which lacks x bits.
Instead, enabling direct mode switches the branch (eg master) to a special
purpose branch (eg annex/direct/master). This branch is not pushed when
syncing; instead any changes that git annex sync commits get written to
master, and it's pushed (along with synced/master) to the remote.
Note that initialization has been changed to always call setDirect,
even if it's just setDirect False for indirect mode. This is needed because
if the user has just cloned a direct mode repo, that nothing has synced
with before, it may have no master branch, and only a annex/direct/master.
Resulting in that branch being checked out locally too. Calling setDirect False
for indirect mode moves back out of this branch, to a new master branch,
and ensures that a manual "git push" doesn't push changes directly to
the annex/direct/master of the remote. (It's possible that the user
makes a commit w/o using git-annex and pushes it, but nothing I can do
about that really.)
This commit was sponsored by Jonathan Harrington.
2013-11-06 01:08:31 +00:00
|
|
|
-- Update the sync branch to match the new state of the branch
|
2016-03-03 20:19:09 +00:00
|
|
|
inRepo $ updateBranch (syncBranch branch) branch
|
2018-10-20 18:12:04 +00:00
|
|
|
|
2016-02-29 20:57:42 +00:00
|
|
|
updateBranch :: Git.Branch -> Git.Branch -> Git.Repo -> IO ()
|
|
|
|
updateBranch syncbranch updateto g =
|
2023-02-08 19:37:28 +00:00
|
|
|
unlessM go $
|
|
|
|
giveup $ "failed to update " ++ Git.fromRef syncbranch
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
2013-03-03 17:39:07 +00:00
|
|
|
go = Git.Command.runBool
|
|
|
|
[ Param "branch"
|
|
|
|
, Param "-f"
|
2014-02-19 05:09:17 +00:00
|
|
|
, Param $ Git.fromRef $ Git.Ref.base syncbranch
|
2016-02-29 20:57:42 +00:00
|
|
|
, Param $ Git.fromRef $ updateto
|
2012-11-12 05:05:04 +00:00
|
|
|
] g
|
2011-12-30 21:38:38 +00:00
|
|
|
|
2016-04-22 18:26:44 +00:00
|
|
|
pullRemote :: SyncOptions -> [Git.Merge.MergeConfig] -> Remote -> CurrBranch -> CommandStart
|
make CommandStart return a StartMessage
The goal is to be able to run CommandStart in the main thread when -J is
used, rather than unncessarily passing it off to a worker thread, which
incurs overhead that is signficant when the CommandStart is going to
quickly decide to stop.
To do that, the message it displays needs to be displayed in the worker
thread, after the CommandStart has run.
Also, the change will mean that CommandStart will no longer necessarily
run with the same Annex state as CommandPerform. While its docs already
said it should avoid modifying Annex state, I audited all the
CommandStart code as part of the conversion. (Note that CommandSeek
already sometimes runs with a different Annex state, and that has not been
a source of any problems, so I am not too worried that this change will
lead to breakage going forward.)
The only modification of Annex state I found was it calling
allowMessages in some Commands that default to noMessages. Dealt with
that by adding a startCustomOutput and a startingUsualMessages.
This lets a command start with noMessages and then select the output it
wants for each CommandStart.
One bit of breakage: onlyActionOn has been removed from commands that used it.
The plan is that, since a StartMessage contains an ActionItem,
when a Key can be extracted from that, the parallel job runner can
run onlyActionOn' automatically. Then commands won't need to worry about
this detail. Future work.
Otherwise, this was a fairly straightforward process of making each
CommandStart compile again. Hopefully other behavior changes were mostly
avoided.
In a few cases, a command had a CommandStart that called a CommandPerform
that then called showStart multiple times. I have collapsed those
down to a single start action. The main command to perhaps suffer from it
is Command.Direct, which used to show a start for each file, and no
longer does.
Another minor behavior change is that some commands used showStart
before, but had an associated file and a Key available, so were changed
to ShowStart with an ActionItemAssociatedFile. That will not change the
normal output or behavior, but --json output will now include the key.
This should not break it for anyone using a real json parser.
2019-06-06 19:42:30 +00:00
|
|
|
pullRemote o mergeconfig remote branch = stopUnless (pure $ pullOption o && wantpull) $
|
2020-09-14 20:49:33 +00:00
|
|
|
starting "pull" ai si $ do
|
2011-12-30 21:38:38 +00:00
|
|
|
showOutput
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
ifM (onlyAnnex o)
|
|
|
|
( do
|
|
|
|
void $ fetch $ map Git.fromRef
|
|
|
|
[ Annex.Branch.name
|
|
|
|
, syncBranch $ Annex.Branch.name
|
|
|
|
]
|
|
|
|
next $ return True
|
|
|
|
, ifM (fetch [])
|
|
|
|
( next $ mergeRemote remote branch mergeconfig o
|
|
|
|
, next $ return True
|
|
|
|
)
|
make CommandStart return a StartMessage
The goal is to be able to run CommandStart in the main thread when -J is
used, rather than unncessarily passing it off to a worker thread, which
incurs overhead that is signficant when the CommandStart is going to
quickly decide to stop.
To do that, the message it displays needs to be displayed in the worker
thread, after the CommandStart has run.
Also, the change will mean that CommandStart will no longer necessarily
run with the same Annex state as CommandPerform. While its docs already
said it should avoid modifying Annex state, I audited all the
CommandStart code as part of the conversion. (Note that CommandSeek
already sometimes runs with a different Annex state, and that has not been
a source of any problems, so I am not too worried that this change will
lead to breakage going forward.)
The only modification of Annex state I found was it calling
allowMessages in some Commands that default to noMessages. Dealt with
that by adding a startCustomOutput and a startingUsualMessages.
This lets a command start with noMessages and then select the output it
wants for each CommandStart.
One bit of breakage: onlyActionOn has been removed from commands that used it.
The plan is that, since a StartMessage contains an ActionItem,
when a Key can be extracted from that, the parallel job runner can
run onlyActionOn' automatically. Then commands won't need to worry about
this detail. Future work.
Otherwise, this was a fairly straightforward process of making each
CommandStart compile again. Hopefully other behavior changes were mostly
avoided.
In a few cases, a command had a CommandStart that called a CommandPerform
that then called showStart multiple times. I have collapsed those
down to a single start action. The main command to perhaps suffer from it
is Command.Direct, which used to show a start for each file, and no
longer does.
Another minor behavior change is that some commands used showStart
before, but had an associated file and a Key available, so were changed
to ShowStart with an ActionItemAssociatedFile. That will not change the
normal output or behavior, but --json output will now include the key.
This should not break it for anyone using a real json parser.
2019-06-06 19:42:30 +00:00
|
|
|
)
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
fetch bs = do
|
2018-06-04 18:31:55 +00:00
|
|
|
repo <- Remote.getRepo remote
|
2021-07-19 15:28:31 +00:00
|
|
|
ms <- Annex.getState Annex.output
|
2018-06-04 18:31:55 +00:00
|
|
|
inRepoWithSshOptionsTo repo (Remote.gitconfig remote) $
|
2021-07-19 15:28:31 +00:00
|
|
|
Git.Command.runBool $ catMaybes
|
|
|
|
[ Just $ Param "fetch"
|
|
|
|
, if commandProgressDisabled' ms
|
|
|
|
then Just $ Param "--quiet"
|
|
|
|
else Nothing
|
|
|
|
, Just $ Param $ Remote.name remote
|
|
|
|
] ++ map Param bs
|
Added remote.<name>.annex-push and remote.<name>.annex-pull
The former can be useful to make remotes that don't get fully synced with
local changes, which comes up in a lot of situations.
The latter was mostly added for symmetry, but could be useful (though less
likely to be).
Implementing `remote.<name>.annex-pull` was a bit tricky, as there's no one
place where git-annex pulls/fetches from remotes. I audited all
instances of "fetch" and "pull". A few cases were left not checking this
config:
* Git.Repair can try to pull missing refs from a remote, and if the local
repo is corrupted, that seems a reasonable thing to do even though
the config would normally prevent it.
* Assistant.WebApp.Gpg and Remote.Gcrypt and Remote.Git do fetches
as part of the setup process of a remote. The config would probably not
be set then, and having the setup fail seems worse than honoring it if it
is already set.
I have not prevented all the code that does a "merge" from merging branches
from remotes with remote.<name>.annex-pull=false. That could perhaps
be done, but it would need a way to map from branch name to remote name,
and the way refspecs work makes that hard to get really correct. So if the
user fetches manually, the git-annex branch will get merged, for example.
Anther way of looking at/justifying this is that the setting is called
"annex-pull", not "annex-merge".
This commit was supported by the NSF-funded DataLad project.
2017-04-05 17:04:02 +00:00
|
|
|
wantpull = remoteAnnexPull (Remote.gitconfig remote)
|
2020-09-14 20:49:33 +00:00
|
|
|
ai = ActionItemOther (Just (Remote.name remote))
|
|
|
|
si = SeekInput []
|
2011-12-10 00:27:22 +00:00
|
|
|
|
remove direct mode remnant of merging unrelated histories
sync, merge, post-receive: Avoid merging unrelated histories, which used to
be allowed only to support direct mode repositories.
(However, sync does still merge unrelated histories when importing trees
from special remotes, and the assistant still merges unrelated histories
always.)
See 556b2ded2ba8270846fa207255b4c2def6ef5d8a for why this was added
back in 2016, for direct mode.
This is a behavior change, which might break something that was relying
on sync merging unrelated histories, but git had a good reason to
prevent it, since it's easy to foot shoot with it, and git-annex should
follow suit.
Sponsored-by: Noam Kremen on Patreon
2021-07-19 15:40:48 +00:00
|
|
|
importRemote :: Bool -> SyncOptions -> Remote -> CurrBranch -> CommandSeek
|
|
|
|
importRemote importcontent o remote currbranch
|
2019-03-09 17:57:49 +00:00
|
|
|
| not (pullOption o) || not wantpull = noop
|
|
|
|
| otherwise = case remoteAnnexTrackingBranch (Remote.gitconfig remote) of
|
|
|
|
Nothing -> noop
|
|
|
|
Just tb -> do
|
2020-04-07 21:41:09 +00:00
|
|
|
let (b, p) = separate' (== (fromIntegral (ord ':'))) (Git.fromRef' tb)
|
2019-03-09 17:57:49 +00:00
|
|
|
let branch = Git.Ref b
|
2020-04-07 21:41:09 +00:00
|
|
|
let subdir = if S.null p
|
2019-03-09 17:57:49 +00:00
|
|
|
then Nothing
|
2020-04-07 21:41:09 +00:00
|
|
|
else Just (asTopFilePath p)
|
2020-09-28 19:29:08 +00:00
|
|
|
if canImportKeys remote importcontent
|
|
|
|
then do
|
2020-09-30 14:41:59 +00:00
|
|
|
Command.Import.seekRemote remote branch subdir importcontent (CheckGitIgnore True)
|
remove direct mode remnant of merging unrelated histories
sync, merge, post-receive: Avoid merging unrelated histories, which used to
be allowed only to support direct mode repositories.
(However, sync does still merge unrelated histories when importing trees
from special remotes, and the assistant still merges unrelated histories
always.)
See 556b2ded2ba8270846fa207255b4c2def6ef5d8a for why this was added
back in 2016, for direct mode.
This is a behavior change, which might break something that was relying
on sync merging unrelated histories, but git had a good reason to
prevent it, since it's easy to foot shoot with it, and git-annex should
follow suit.
Sponsored-by: Noam Kremen on Patreon
2021-07-19 15:40:48 +00:00
|
|
|
-- Importing generates a branch
|
|
|
|
-- that is not initially connected
|
|
|
|
-- to the current branch, so allow
|
|
|
|
-- merging unrelated histories when
|
|
|
|
-- mergeing it.
|
|
|
|
mc <- mergeConfig True
|
|
|
|
void $ mergeRemote remote currbranch mc o
|
2020-09-28 19:29:08 +00:00
|
|
|
else warning $ "Cannot import from " ++ Remote.name remote ++ " when not syncing content."
|
2019-03-09 17:57:49 +00:00
|
|
|
where
|
|
|
|
wantpull = remoteAnnexPull (Remote.gitconfig remote)
|
|
|
|
|
2020-12-23 16:10:39 +00:00
|
|
|
{- Handle a remote that is populated by a third party, by listing
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
- the contents of the remote, and then adding only the files on it that
|
|
|
|
- importKey identifies to a tree. The tree is only used to keep track
|
|
|
|
- of where keys are located on the remote, no remote tracking branch is
|
|
|
|
- updated, because the filenames are the names of annex object files,
|
|
|
|
- not suitable for a tracking branch. Does not transfer any content. -}
|
2020-12-23 16:10:39 +00:00
|
|
|
pullThirdPartyPopulated :: SyncOptions -> Remote -> CommandSeek
|
|
|
|
pullThirdPartyPopulated o remote
|
|
|
|
| not (pullOption o) || not wantpull = noop
|
|
|
|
| not (canImportKeys remote False) = noop
|
|
|
|
| otherwise = void $ includeCommandAction $ starting "list" ai si $
|
2020-12-21 20:03:27 +00:00
|
|
|
Command.Import.listContents' remote ImportTree (CheckGitIgnore False) go
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
where
|
2020-12-22 18:35:02 +00:00
|
|
|
go (Just importable) = importKeys remote ImportTree False True importable >>= \case
|
2020-12-21 20:03:27 +00:00
|
|
|
Just importablekeys -> do
|
|
|
|
(_imported, updatestate) <- recordImportTree remote ImportTree importablekeys
|
|
|
|
next $ do
|
|
|
|
updatestate
|
|
|
|
return True
|
|
|
|
Nothing -> next $ return False
|
2020-12-22 18:35:02 +00:00
|
|
|
go Nothing = next $ return True -- unchanged from before
|
2020-12-21 20:03:27 +00:00
|
|
|
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
ai = ActionItemOther (Just (Remote.name remote))
|
|
|
|
si = SeekInput []
|
2020-12-23 16:10:39 +00:00
|
|
|
|
|
|
|
wantpull = remoteAnnexPull (Remote.gitconfig remote)
|
add thirdPartyPopulated interface
This is to support, eg a borg repo as a special remote, which is
populated not by running git-annex commands, but by using borg. Then
git-annex sync lists the content of the remote, learns which files are
annex objects, and treats those as present in the remote.
So, most of the import machinery is reused, to a new purpose. While
normally importtree maintains a remote tracking branch, this does not,
because the files stored in the remote are annex object files, not
user-visible filenames. But, internally, a git tree is still generated,
of the files on the remote that are annex objects. This tree is used
by retrieveExportWithContentIdentifier, etc. As with other import/export
remotes, that the tree is recorded in the export log, and gets grafted
into the git-annex branch.
importKey changed to be able to return Nothing, to indicate when an
ImportLocation is not an annex object and so should be skipped from
being included in the tree.
It did not seem to make sense to have git-annex import do this, since
from the user's perspective, it's not like other imports. So only
git-annex sync does it.
Note that, git-annex sync does not yet download objects from such
remotes that are preferred content. importKeys is run with
content downloading disabled, to avoid getting the content of all
objects. Perhaps what's needed is for seekSyncContent to be run with these
remotes, but I don't know if it will just work (in particular, it needs
to avoid trying to transfer objects to them), so I skipped that for now.
(Untested and unused as of yet.)
This commit was sponsored by Jochen Bartl on Patreon.
2020-12-18 18:52:57 +00:00
|
|
|
|
2011-12-30 23:11:22 +00:00
|
|
|
{- The remote probably has both a master and a synced/master branch.
|
|
|
|
- Which to merge from? Well, the master has whatever latest changes
|
2013-06-12 18:54:23 +00:00
|
|
|
- were committed (or pushed changes, if this is a bare remote),
|
|
|
|
- while the synced/master may have changes that some
|
2012-12-12 17:06:03 +00:00
|
|
|
- other remote synced to this remote. So, merge them both. -}
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
mergeRemote :: Remote -> CurrBranch -> [Git.Merge.MergeConfig] -> SyncOptions -> CommandCleanup
|
|
|
|
mergeRemote remote currbranch mergeconfig o = ifM isBareRepo
|
2015-01-05 17:40:49 +00:00
|
|
|
( return True
|
2016-02-29 19:57:47 +00:00
|
|
|
, case currbranch of
|
2016-02-29 19:23:08 +00:00
|
|
|
(Nothing, _) -> do
|
2015-01-05 17:40:49 +00:00
|
|
|
branch <- inRepo Git.Branch.currentUnsafe
|
2016-02-29 19:57:47 +00:00
|
|
|
mergelisted (pure (branchlist branch))
|
|
|
|
(Just branch, _) -> do
|
2016-02-29 20:57:42 +00:00
|
|
|
inRepo $ updateBranch (syncBranch branch) branch
|
2016-02-29 19:57:47 +00:00
|
|
|
mergelisted (tomerge (branchlist (Just branch)))
|
2015-01-05 17:40:49 +00:00
|
|
|
)
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
2016-02-29 19:57:47 +00:00
|
|
|
mergelisted getlist = and <$>
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
(mapM (merge currbranch mergeconfig o Git.Branch.ManualCommit . remoteBranch remote) =<< getlist)
|
2014-02-11 17:11:49 +00:00
|
|
|
tomerge = filterM (changed remote)
|
2012-11-12 05:05:04 +00:00
|
|
|
branchlist Nothing = []
|
2023-02-08 17:55:55 +00:00
|
|
|
branchlist (Just branch) = [origBranch branch, syncBranch branch]
|
2011-12-30 23:11:22 +00:00
|
|
|
|
2016-02-29 19:23:08 +00:00
|
|
|
pushRemote :: SyncOptions -> Remote -> CurrBranch -> CommandStart
|
|
|
|
pushRemote _o _remote (Nothing, _) = stop
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
pushRemote o remote (Just branch, _) = do
|
|
|
|
onlyannex <- onlyAnnex o
|
|
|
|
let mainbranch = if onlyannex then Nothing else Just branch
|
|
|
|
stopUnless (pure (pushOption o) <&&> needpush mainbranch) $
|
2020-09-14 20:49:33 +00:00
|
|
|
starting "push" ai si $ next $ do
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
repo <- Remote.getRepo remote
|
|
|
|
showOutput
|
2021-07-19 15:28:31 +00:00
|
|
|
ms <- Annex.getState Annex.output
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
ok <- inRepoWithSshOptionsTo repo gc $
|
2021-07-19 15:28:31 +00:00
|
|
|
pushBranch remote mainbranch ms
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
if ok
|
|
|
|
then postpushupdate repo
|
|
|
|
else do
|
|
|
|
warning $ unwords [ "Pushing to " ++ Remote.name remote ++ " failed." ]
|
|
|
|
return ok
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
2020-09-14 20:49:33 +00:00
|
|
|
ai = ActionItemOther (Just (Remote.name remote))
|
|
|
|
si = SeekInput []
|
2018-06-05 17:03:42 +00:00
|
|
|
gc = Remote.gitconfig remote
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
needpush mainbranch
|
Added remote.<name>.annex-push and remote.<name>.annex-pull
The former can be useful to make remotes that don't get fully synced with
local changes, which comes up in a lot of situations.
The latter was mostly added for symmetry, but could be useful (though less
likely to be).
Implementing `remote.<name>.annex-pull` was a bit tricky, as there's no one
place where git-annex pulls/fetches from remotes. I audited all
instances of "fetch" and "pull". A few cases were left not checking this
config:
* Git.Repair can try to pull missing refs from a remote, and if the local
repo is corrupted, that seems a reasonable thing to do even though
the config would normally prevent it.
* Assistant.WebApp.Gpg and Remote.Gcrypt and Remote.Git do fetches
as part of the setup process of a remote. The config would probably not
be set then, and having the setup fail seems worse than honoring it if it
is already set.
I have not prevented all the code that does a "merge" from merging branches
from remotes with remote.<name>.annex-pull=false. That could perhaps
be done, but it would need a way to map from branch name to remote name,
and the way refspecs work makes that hard to get really correct. So if the
user fetches manually, the git-annex branch will get merged, for example.
Anther way of looking at/justifying this is that the setting is called
"annex-pull", not "annex-merge".
This commit was supported by the NSF-funded DataLad project.
2017-04-05 17:04:02 +00:00
|
|
|
| remoteAnnexReadOnly gc = return False
|
|
|
|
| not (remoteAnnexPush gc) = return False
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
| otherwise = anyM (newer remote) $ catMaybes
|
|
|
|
[ syncBranch <$> mainbranch
|
|
|
|
, Just (Annex.Branch.name)
|
|
|
|
]
|
2019-09-11 18:41:51 +00:00
|
|
|
-- Older remotes on crippled filesystems may not have a
|
|
|
|
-- post-receive hook set up, so when updateInstead emulation
|
|
|
|
-- is needed, run post-receive manually.
|
2018-06-05 17:03:42 +00:00
|
|
|
postpushupdate repo = case Git.repoWorkTree repo of
|
|
|
|
Nothing -> return True
|
|
|
|
Just wt -> ifM needemulation
|
2020-12-15 14:44:36 +00:00
|
|
|
( gitAnnexChildProcess "post-receive" []
|
2020-08-25 18:57:25 +00:00
|
|
|
(\cp -> cp { cwd = Just (fromRawFilePath wt) })
|
|
|
|
(\_ _ _ pid -> waitForProcess pid >>= return . \case
|
|
|
|
ExitSuccess -> True
|
|
|
|
_ -> False
|
|
|
|
)
|
2018-06-05 17:03:42 +00:00
|
|
|
, return True
|
|
|
|
)
|
|
|
|
where
|
2020-04-17 21:09:29 +00:00
|
|
|
needemulation = Remote.Git.onLocalRepo repo $
|
2018-06-05 17:03:42 +00:00
|
|
|
(annexCrippledFileSystem <$> Annex.getGitConfig)
|
|
|
|
<&&>
|
|
|
|
needUpdateInsteadEmulation
|
2012-06-22 19:46:21 +00:00
|
|
|
|
2013-08-29 18:15:32 +00:00
|
|
|
{- Pushes a regular branch like master to a remote. Also pushes the git-annex
|
|
|
|
- branch.
|
|
|
|
-
|
2017-02-15 20:13:30 +00:00
|
|
|
- If the remote is a bare git repository, it's best to push the regular
|
2013-08-29 18:15:32 +00:00
|
|
|
- branch directly to it, so that cloning/pulling will get it.
|
|
|
|
- On the other hand, if it's not bare, pushing to the checked out branch
|
2017-02-15 20:13:30 +00:00
|
|
|
- will generally fail (except with receive.denyCurrentBranch=updateInstead),
|
|
|
|
- and this is why we push to its syncBranch.
|
2013-06-12 18:54:23 +00:00
|
|
|
-
|
|
|
|
- Git offers no way to tell if a remote is bare or not, so both methods
|
|
|
|
- are tried.
|
|
|
|
-
|
2017-02-15 20:13:30 +00:00
|
|
|
- The direct push is likely to spew an ugly error message, so its stderr is
|
|
|
|
- often elided. Since git progress display goes to stderr too, the
|
|
|
|
- sync push is done first, and actually sends the data. Then the
|
|
|
|
- direct push is tried, with stderr discarded, to update the branch ref
|
|
|
|
- on the remote.
|
2013-08-29 18:15:32 +00:00
|
|
|
-
|
2021-06-21 16:32:21 +00:00
|
|
|
- The sync push first sends the synced/master branch,
|
|
|
|
- and then forces the update of the remote synced/git-annex branch.
|
|
|
|
-
|
|
|
|
- Since some providers like github may treat the first branch sent
|
|
|
|
- as the default branch, it's better to make that be synced/master than
|
|
|
|
- synced/git-annex. (Although neither is ideal, it's the best that
|
|
|
|
- can be managed given the constraints on order.)
|
|
|
|
-
|
|
|
|
- The forcing is necessary if a transition has rewritten the git-annex branch.
|
2013-08-29 18:15:32 +00:00
|
|
|
- Normally any changes to the git-annex branch get pulled and merged before
|
|
|
|
- this push, so this forcing is unlikely to overwrite new data pushed
|
|
|
|
- in from another repository that is also syncing.
|
|
|
|
-
|
|
|
|
- But overwriting of data on synced/git-annex can happen, in a race.
|
|
|
|
- The only difference caused by using a forced push in that case is that
|
|
|
|
- the last repository to push wins the race, rather than the first to push.
|
2013-06-12 18:54:23 +00:00
|
|
|
-}
|
2021-07-19 15:28:31 +00:00
|
|
|
pushBranch :: Remote -> Maybe Git.Branch -> MessageState -> Git.Repo -> IO Bool
|
|
|
|
pushBranch remote mbranch ms g = directpush `after` annexpush `after` syncpush
|
2013-06-12 18:54:23 +00:00
|
|
|
where
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
syncpush = flip Git.Command.runBool g $ pushparams $ catMaybes
|
2023-02-08 17:55:55 +00:00
|
|
|
[ (refspec . origBranch) <$> mbranch
|
2021-06-21 16:32:21 +00:00
|
|
|
, Just $ Git.Branch.forcePush $ refspec Annex.Branch.name
|
2013-08-29 18:15:32 +00:00
|
|
|
]
|
2017-02-17 18:00:01 +00:00
|
|
|
annexpush = void $ tryIO $ flip Git.Command.runQuiet g $ pushparams
|
|
|
|
[ Git.fromRef $ Git.Ref.base $ Annex.Branch.name ]
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
directpush = case mbranch of
|
|
|
|
Nothing -> noop
|
2017-02-15 20:13:30 +00:00
|
|
|
-- Git prints out an error message when this fails.
|
|
|
|
-- In the default configuration of receive.denyCurrentBranch,
|
|
|
|
-- the error message mentions that config setting
|
|
|
|
-- (and should even if it is localized), and is quite long,
|
|
|
|
-- and the user was not intending to update the checked out
|
|
|
|
-- branch, so in that case, avoid displaying the error
|
|
|
|
-- message. Do display other error messages though,
|
|
|
|
-- including the error displayed when
|
|
|
|
-- receive.denyCurrentBranch=updateInstead -- the user
|
|
|
|
-- will want to see that one.
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
Just branch -> do
|
|
|
|
let p = flip Git.Command.gitCreateProcess g $ pushparams
|
2023-02-08 17:55:55 +00:00
|
|
|
[ Git.fromRef $ Git.Ref.base $ origBranch branch ]
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
(transcript, ok) <- processTranscript' p Nothing
|
|
|
|
when (not ok && not ("denyCurrentBranch" `isInfixOf` transcript)) $
|
|
|
|
hPutStr stderr transcript
|
2021-07-19 15:28:31 +00:00
|
|
|
pushparams branches = catMaybes
|
|
|
|
[ Just $ Param "push"
|
|
|
|
, if commandProgressDisabled' ms
|
|
|
|
then Just $ Param "--quiet"
|
|
|
|
else Nothing
|
|
|
|
, Just $ Param $ Remote.name remote
|
2013-08-29 18:15:32 +00:00
|
|
|
] ++ map Param branches
|
2012-11-12 05:05:04 +00:00
|
|
|
refspec b = concat
|
2014-02-19 05:09:17 +00:00
|
|
|
[ Git.fromRef $ Git.Ref.base b
|
2012-11-12 05:05:04 +00:00
|
|
|
, ":"
|
2014-02-19 05:09:17 +00:00
|
|
|
, Git.fromRef $ Git.Ref.base $ syncBranch b
|
2012-11-12 05:05:04 +00:00
|
|
|
]
|
2011-12-29 17:37:30 +00:00
|
|
|
|
2014-02-01 14:49:50 +00:00
|
|
|
commitAnnex :: CommandStart
|
|
|
|
commitAnnex = do
|
2018-08-02 18:06:06 +00:00
|
|
|
Annex.Branch.commit =<< Annex.Branch.commitMessage
|
2014-02-01 14:49:50 +00:00
|
|
|
stop
|
|
|
|
|
2011-12-30 20:03:41 +00:00
|
|
|
mergeAnnex :: CommandStart
|
2011-12-30 21:38:38 +00:00
|
|
|
mergeAnnex = do
|
2013-09-25 07:09:06 +00:00
|
|
|
void Annex.Branch.forceUpdate
|
2011-12-30 21:38:38 +00:00
|
|
|
stop
|
2011-12-31 06:18:16 +00:00
|
|
|
|
2011-12-31 08:11:39 +00:00
|
|
|
changed :: Remote -> Git.Ref -> Annex Bool
|
2011-12-31 07:01:18 +00:00
|
|
|
changed remote b = do
|
|
|
|
let r = remoteBranch remote b
|
2012-03-14 21:43:34 +00:00
|
|
|
ifM (inRepo $ Git.Ref.exists r)
|
|
|
|
( inRepo $ Git.Branch.changed b r
|
|
|
|
, return False
|
|
|
|
)
|
2011-12-31 07:01:18 +00:00
|
|
|
|
2011-12-31 08:11:39 +00:00
|
|
|
newer :: Remote -> Git.Ref -> Annex Bool
|
2011-12-31 07:01:18 +00:00
|
|
|
newer remote b = do
|
|
|
|
let r = remoteBranch remote b
|
2012-03-14 21:43:34 +00:00
|
|
|
ifM (inRepo $ Git.Ref.exists r)
|
|
|
|
( inRepo $ Git.Branch.changed r b
|
|
|
|
, return True
|
|
|
|
)
|
2014-01-19 21:35:36 +00:00
|
|
|
|
2018-10-19 19:17:48 +00:00
|
|
|
{- Without --all, only looks at files in the work tree.
|
|
|
|
- (Or, when in an ajusted branch where some files are hidden, at files in
|
|
|
|
- the original branch.)
|
|
|
|
-
|
2020-09-24 19:12:09 +00:00
|
|
|
- With --all, when preferred content expressions look at filenames,
|
|
|
|
- makes a first pass over the files in the work tree so those preferred
|
|
|
|
- content expressions will match. The second pass is over all keys,
|
|
|
|
- and only preferred content expressions that don't look at filenames
|
|
|
|
- will match.
|
2015-06-16 22:38:12 +00:00
|
|
|
-
|
2015-08-14 17:49:55 +00:00
|
|
|
- Returns true if any file transfers were made.
|
|
|
|
-
|
|
|
|
- When concurrency is enabled, files are processed concurrently.
|
2014-01-19 21:35:36 +00:00
|
|
|
-}
|
2018-10-19 19:17:48 +00:00
|
|
|
seekSyncContent :: SyncOptions -> [Remote] -> CurrBranch -> Annex Bool
|
2019-04-10 16:42:10 +00:00
|
|
|
seekSyncContent _ [] _ = return False
|
2018-10-19 19:17:48 +00:00
|
|
|
seekSyncContent o rs currbranch = do
|
2014-02-11 17:11:49 +00:00
|
|
|
mvar <- liftIO newEmptyMVar
|
2015-07-09 23:03:21 +00:00
|
|
|
bloom <- case keyOptions o of
|
2020-09-24 19:12:09 +00:00
|
|
|
Just WantAllKeys -> ifM preferredcontentmatchesfilenames
|
|
|
|
( Just <$> genBloomFilter (seekworktree mvar (WorkTreeItems []))
|
2020-09-24 19:37:39 +00:00
|
|
|
, pure Nothing
|
2020-09-24 19:12:09 +00:00
|
|
|
)
|
2018-10-19 19:17:48 +00:00
|
|
|
_ -> case currbranch of
|
2018-10-19 21:51:25 +00:00
|
|
|
(Just origbranch, Just adj) | adjustmentHidesFiles adj -> do
|
2020-05-28 19:55:17 +00:00
|
|
|
l <- workTreeItems' (AllowHidden True) ww (contentOfOption o)
|
2018-10-19 21:51:25 +00:00
|
|
|
seekincludinghidden origbranch mvar l (const noop)
|
|
|
|
pure Nothing
|
|
|
|
_ -> do
|
2020-05-28 19:55:17 +00:00
|
|
|
l <- workTreeItems ww (contentOfOption o)
|
2018-10-19 19:17:48 +00:00
|
|
|
seekworktree mvar l (const noop)
|
|
|
|
pure Nothing
|
2020-09-24 18:23:25 +00:00
|
|
|
waitForAllRunningCommandActions
|
2015-07-09 23:03:21 +00:00
|
|
|
withKeyOptions' (keyOptions o) False
|
2021-03-02 17:46:12 +00:00
|
|
|
(return (const (commandAction . gokey mvar bloom)))
|
2015-07-09 23:03:21 +00:00
|
|
|
(const noop)
|
when workTreeItems finds a problem with a parameter, don't go on to process it
Part of workTreeItems is trying detect a case
where git porcelain refuses to process a file, and where
git ls-files silently outputs nothing. But, it's hard to perfectly
replicate git's behavior, and besides, git's behavior could change.
So it could be that we warn, but then git ls-files does not skip over
it, and so git-annex also processes it after warning about it.
So, if we think we have a problem with a parameter, display the warning,
and skip processing it at all.
Implementing this was complicated by needing to handle the case where
all command-line parameters get filtered out this way. Which is
different than the case where there are none, because we don't want to
operate on all files in this new case..
2020-08-06 17:47:45 +00:00
|
|
|
(WorkTreeItems [])
|
2020-05-26 18:00:51 +00:00
|
|
|
waitForAllRunningCommandActions
|
2014-02-01 14:49:50 +00:00
|
|
|
liftIO $ not <$> isEmptyMVar mvar
|
2014-01-20 17:31:03 +00:00
|
|
|
where
|
2020-07-13 21:04:02 +00:00
|
|
|
seekworktree mvar l bloomfeeder = do
|
|
|
|
let seeker = AnnexedFileSeeker
|
2020-07-22 18:23:28 +00:00
|
|
|
{ startAction = gofile bloomfeeder mvar
|
2020-07-13 21:04:02 +00:00
|
|
|
, checkContentPresent = Nothing
|
|
|
|
, usesLocationLog = True
|
|
|
|
}
|
|
|
|
seekFilteredKeys seeker $
|
2020-07-13 19:02:52 +00:00
|
|
|
seekHelper fst3 ww LsFiles.inRepoDetails l
|
2018-10-19 21:51:25 +00:00
|
|
|
|
2020-07-13 19:02:52 +00:00
|
|
|
seekincludinghidden origbranch mvar l bloomfeeder =
|
2022-10-26 17:58:20 +00:00
|
|
|
let filterer = \(si, f) -> lookupKey f >>= \case
|
|
|
|
Just k -> (commandAction $ gofile bloomfeeder mvar si f k)
|
|
|
|
Nothing -> noop
|
|
|
|
in seekFiltered (const (pure True)) filterer $
|
2020-07-13 19:02:52 +00:00
|
|
|
seekHelper id ww (LsFiles.inRepoOrBranch origbranch) l
|
2018-10-19 21:51:25 +00:00
|
|
|
|
2020-05-28 19:55:17 +00:00
|
|
|
ww = WarnUnmatchLsFiles
|
|
|
|
|
2020-09-14 20:49:33 +00:00
|
|
|
gofile bloom mvar _ f k =
|
2020-07-13 19:02:52 +00:00
|
|
|
go (Right bloom) mvar (AssociatedFile (Just f)) k
|
2018-10-19 21:51:25 +00:00
|
|
|
|
2020-09-14 20:49:33 +00:00
|
|
|
gokey mvar bloom (_, k, _) =
|
2020-07-13 19:02:52 +00:00
|
|
|
go (Left bloom) mvar (AssociatedFile Nothing) k
|
2018-10-19 19:17:48 +00:00
|
|
|
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
go ebloom mvar af k = do
|
|
|
|
let ai = OnlyActionOn k (ActionItemKey k)
|
2020-07-22 18:23:28 +00:00
|
|
|
startingNoMessage ai $ do
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
whenM (syncFile ebloom rs af k) $
|
|
|
|
void $ liftIO $ tryPutMVar mvar ()
|
|
|
|
next $ return True
|
2014-01-20 17:31:03 +00:00
|
|
|
|
2020-09-24 19:12:09 +00:00
|
|
|
preferredcontentmatchesfilenames =
|
|
|
|
preferredcontentmatchesfilenames' Nothing
|
|
|
|
<||> anyM (preferredcontentmatchesfilenames' . Just . Remote.uuid) rs
|
|
|
|
preferredcontentmatchesfilenames' =
|
|
|
|
introspectPreferredRequiredContent matchNeedsFileName
|
|
|
|
|
2015-06-16 23:07:14 +00:00
|
|
|
{- If it's preferred content, and we don't have it, get it from one of the
|
|
|
|
- listed remotes (preferring the cheaper earlier ones).
|
|
|
|
-
|
|
|
|
- Send it to each remote that doesn't have it, and for which it's
|
|
|
|
- preferred content.
|
|
|
|
-
|
|
|
|
- Drop it locally if it's not preferred content (honoring numcopies).
|
|
|
|
-
|
|
|
|
- Drop it from each remote that has it, where it's not preferred content
|
|
|
|
- (honoring numcopies).
|
2015-08-14 17:49:55 +00:00
|
|
|
-
|
|
|
|
- Returns True if any file transfers were made.
|
2015-06-16 23:07:14 +00:00
|
|
|
-}
|
2015-08-14 17:49:55 +00:00
|
|
|
syncFile :: Either (Maybe (Bloom Key)) (Key -> Annex ()) -> [Remote] -> AssociatedFile -> Key -> Annex Bool
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
syncFile ebloom rs af k = do
|
2018-12-18 17:58:12 +00:00
|
|
|
inhere <- inAnnex k
|
2018-08-01 18:22:52 +00:00
|
|
|
locs <- map Remote.uuid <$> Remote.keyPossibilities k
|
2014-01-19 21:35:36 +00:00
|
|
|
let (have, lack) = partition (\r -> Remote.uuid r `elem` locs) rs
|
|
|
|
|
2018-12-18 17:58:12 +00:00
|
|
|
got <- anyM id =<< handleget have inhere
|
2021-10-01 16:02:35 +00:00
|
|
|
let inhere' = inhere || got
|
|
|
|
putrs <- handleput lack inhere'
|
2014-01-20 17:31:03 +00:00
|
|
|
|
2014-02-03 02:46:55 +00:00
|
|
|
u <- getUUID
|
2021-10-01 16:02:35 +00:00
|
|
|
let locs' = concat [if inhere' then [u] else [], putrs, locs]
|
2014-02-03 02:46:55 +00:00
|
|
|
|
2020-09-24 19:12:09 +00:00
|
|
|
-- To handle --all, a bloom filter is populated with all the keys
|
|
|
|
-- of files in the working tree in the first pass. On the second
|
|
|
|
-- pass, avoid dropping keys that were seen in the first pass, which
|
|
|
|
-- would happen otherwise when preferred content matches on the
|
|
|
|
-- filename, which is not available in the second pass.
|
|
|
|
-- (When the preferred content expressions do not match on
|
|
|
|
-- filenames, the first pass is skipped for speed.)
|
2015-06-16 22:38:12 +00:00
|
|
|
--
|
|
|
|
-- When there's a false positive in the bloom filter, the result
|
|
|
|
-- is keeping a key that preferred content doesn't really want.
|
|
|
|
seenbloom <- case ebloom of
|
2015-06-16 23:04:20 +00:00
|
|
|
Left Nothing -> pure False
|
|
|
|
Left (Just bloom) -> pure (elemB k bloom)
|
2015-06-16 22:38:12 +00:00
|
|
|
Right bloomfeeder -> bloomfeeder k >> return False
|
|
|
|
unless seenbloom $
|
|
|
|
-- Using callCommandAction rather than
|
|
|
|
-- includeCommandAction for drops,
|
|
|
|
-- because a failure to drop does not mean
|
|
|
|
-- the sync failed.
|
2020-09-14 20:49:33 +00:00
|
|
|
handleDropsFrom locs' rs "unwanted" True k af si []
|
2015-10-08 20:55:11 +00:00
|
|
|
callCommandAction
|
2015-08-14 17:49:55 +00:00
|
|
|
|
|
|
|
return (got || not (null putrs))
|
2014-01-20 17:31:03 +00:00
|
|
|
where
|
2018-12-18 17:58:12 +00:00
|
|
|
wantget have inhere = allM id
|
2014-01-19 21:35:36 +00:00
|
|
|
[ pure (not $ null have)
|
2018-12-18 17:58:12 +00:00
|
|
|
, pure (not inhere)
|
2015-06-16 19:07:03 +00:00
|
|
|
, wantGet True (Just k) af
|
2014-01-19 21:35:36 +00:00
|
|
|
]
|
2018-12-18 17:58:12 +00:00
|
|
|
handleget have inhere = ifM (wantget have inhere)
|
2014-01-19 21:35:36 +00:00
|
|
|
( return [ get have ]
|
|
|
|
, return []
|
|
|
|
)
|
2020-09-14 20:49:33 +00:00
|
|
|
get have = includeCommandAction $ starting "get" ai si $
|
2019-06-17 18:58:02 +00:00
|
|
|
stopUnless (getKey' k af have) $
|
|
|
|
next $ return True
|
2014-01-19 21:35:36 +00:00
|
|
|
|
|
|
|
wantput r
|
2014-04-12 19:59:34 +00:00
|
|
|
| Remote.readonly r || remoteAnnexReadOnly (Remote.gitconfig r) = return False
|
2020-12-23 16:10:39 +00:00
|
|
|
| isThirdPartyPopulated r = return False
|
2022-07-28 17:26:03 +00:00
|
|
|
| otherwise = wantGetBy True (Just k) af (Remote.uuid r)
|
2021-10-01 16:02:35 +00:00
|
|
|
handleput lack inhere
|
|
|
|
| inhere = catMaybes <$>
|
|
|
|
( forM lack $ \r ->
|
|
|
|
ifM (wantput r <&&> put r)
|
|
|
|
( return (Just (Remote.uuid r))
|
|
|
|
, return Nothing
|
|
|
|
)
|
|
|
|
)
|
|
|
|
| otherwise = return []
|
2016-03-09 19:04:00 +00:00
|
|
|
put dest = includeCommandAction $
|
2020-09-14 20:49:33 +00:00
|
|
|
Command.Move.toStart' dest Command.Move.RemoveNever af k ai si
|
2019-06-06 16:53:24 +00:00
|
|
|
|
|
|
|
ai = mkActionItem (k, af)
|
2020-09-14 20:49:33 +00:00
|
|
|
si = SeekInput []
|
2017-09-19 18:20:47 +00:00
|
|
|
|
2019-02-23 19:48:25 +00:00
|
|
|
{- When a remote has an annex-tracking-branch configuration, change the export
|
|
|
|
- to contain the current content of the branch. Otherwise, transfer any files
|
2017-09-20 18:37:20 +00:00
|
|
|
- that were part of an export but are not in the remote yet.
|
|
|
|
-
|
|
|
|
- Returns True if any file transfers were made.
|
|
|
|
-}
|
2019-03-09 17:21:49 +00:00
|
|
|
seekExportContent :: Maybe SyncOptions -> [Remote] -> CurrBranch -> Annex Bool
|
|
|
|
seekExportContent o rs (currbranch, _) = or <$> forM rs go
|
2017-09-19 18:20:47 +00:00
|
|
|
where
|
2019-03-09 17:21:49 +00:00
|
|
|
go r
|
|
|
|
| not (maybe True pullOption o) = return False
|
|
|
|
| not (remoteAnnexPush (Remote.gitconfig r)) = return False
|
|
|
|
| otherwise = bracket
|
|
|
|
(Export.openDb (Remote.uuid r))
|
|
|
|
Export.closeDb
|
|
|
|
(\db -> Export.writeLockDbWhile db (go' r db))
|
2019-05-20 15:54:55 +00:00
|
|
|
go' r db = case remoteAnnexTrackingBranch (Remote.gitconfig r) of
|
2021-12-23 18:44:03 +00:00
|
|
|
Nothing -> cannotupdateexport r db Nothing
|
2019-05-20 15:54:55 +00:00
|
|
|
Just b -> do
|
|
|
|
mtree <- inRepo $ Git.Ref.tree b
|
|
|
|
mtbcommitsha <- Command.Export.getExportCommit r b
|
|
|
|
case (mtree, mtbcommitsha) of
|
|
|
|
(Just tree, Just _) -> do
|
2021-03-12 17:28:43 +00:00
|
|
|
filteredtree <- Command.Export.filterExport r tree
|
2019-05-20 15:54:55 +00:00
|
|
|
Command.Export.changeExport r db filteredtree
|
|
|
|
Command.Export.fillExport r db filteredtree mtbcommitsha
|
2021-12-23 18:44:03 +00:00
|
|
|
_ -> cannotupdateexport r db (Just b)
|
2019-05-20 15:54:55 +00:00
|
|
|
|
2021-12-23 18:44:03 +00:00
|
|
|
cannotupdateexport r db mtb = do
|
2018-09-27 19:35:46 +00:00
|
|
|
exported <- getExport (Remote.uuid r)
|
2021-12-23 18:44:03 +00:00
|
|
|
maybe noop (warncannotupdateexport r mtb exported) currbranch
|
|
|
|
fillexistingexport r db (exportedTreeishes exported) Nothing
|
2018-09-27 19:35:46 +00:00
|
|
|
|
2021-12-23 18:44:03 +00:00
|
|
|
warncannotupdateexport r mtb exported currb = case mtb of
|
|
|
|
Nothing -> inRepo (Git.Ref.tree currb) >>= \case
|
|
|
|
Just currt | not (any (== currt) (exportedTreeishes exported)) ->
|
|
|
|
showLongNote $ unwords
|
|
|
|
[ notupdating
|
|
|
|
, "to reflect changes to the tree, because export"
|
|
|
|
, "tracking is not enabled. "
|
|
|
|
, "(Set " ++ gitconfig ++ " to enable it.)"
|
|
|
|
]
|
|
|
|
_ -> noop
|
|
|
|
Just b -> showLongNote $ unwords
|
|
|
|
[ notupdating
|
2022-10-04 17:30:22 +00:00
|
|
|
, "because " ++ Git.fromRef b ++ " does not exist."
|
2021-12-23 18:44:03 +00:00
|
|
|
, "(As configured by " ++ gitconfig ++ ")"
|
|
|
|
]
|
2019-03-01 20:08:18 +00:00
|
|
|
where
|
2020-02-19 17:45:11 +00:00
|
|
|
gitconfig = show (remoteAnnexConfig r "tracking-branch")
|
2021-12-23 18:44:03 +00:00
|
|
|
notupdating = "Not updating export to " ++ Remote.name r
|
2018-09-27 19:35:46 +00:00
|
|
|
|
2021-12-23 18:44:03 +00:00
|
|
|
fillexistingexport _ _ [] _ = return False
|
|
|
|
fillexistingexport r db (tree:[]) mtbcommitsha = do
|
2021-03-12 17:28:43 +00:00
|
|
|
-- The tree was already filtered when it was exported, so
|
|
|
|
-- does not need be be filtered again now, when we're only
|
2021-12-23 18:44:03 +00:00
|
|
|
-- filling in any files that did not get transferred
|
|
|
|
-- to the existing exported tree.
|
2021-03-12 17:28:43 +00:00
|
|
|
let filteredtree = Command.Export.ExportFiltered tree
|
2019-05-20 15:54:55 +00:00
|
|
|
Command.Export.fillExport r db filteredtree mtbcommitsha
|
2021-12-23 18:44:03 +00:00
|
|
|
fillexistingexport r _ _ _ = do
|
2019-04-09 17:03:59 +00:00
|
|
|
warnExportImportConflict r
|
2017-09-19 18:20:47 +00:00
|
|
|
return False
|
2017-09-28 18:14:07 +00:00
|
|
|
|
|
|
|
cleanupLocal :: CurrBranch -> CommandStart
|
|
|
|
cleanupLocal (Nothing, _) = stop
|
2020-09-14 20:49:33 +00:00
|
|
|
cleanupLocal (Just currb, _) = starting "cleanup" ai si $ next $ do
|
|
|
|
delbranch $ syncBranch currb
|
|
|
|
delbranch $ syncBranch $ Git.Ref.base $ Annex.Branch.name
|
|
|
|
mapM_ (\(s,r) -> inRepo $ Git.Ref.delete s r) =<< listTaggedBranches
|
|
|
|
return True
|
2017-09-28 18:14:07 +00:00
|
|
|
where
|
|
|
|
delbranch b = whenM (inRepo $ Git.Ref.exists $ Git.Ref.branchRef b) $
|
|
|
|
inRepo $ Git.Branch.delete b
|
2020-09-14 20:49:33 +00:00
|
|
|
ai = ActionItemOther (Just "local")
|
|
|
|
si = SeekInput []
|
2017-09-28 18:14:07 +00:00
|
|
|
|
|
|
|
cleanupRemote :: Remote -> CurrBranch -> CommandStart
|
|
|
|
cleanupRemote _ (Nothing, _) = stop
|
make CommandStart return a StartMessage
The goal is to be able to run CommandStart in the main thread when -J is
used, rather than unncessarily passing it off to a worker thread, which
incurs overhead that is signficant when the CommandStart is going to
quickly decide to stop.
To do that, the message it displays needs to be displayed in the worker
thread, after the CommandStart has run.
Also, the change will mean that CommandStart will no longer necessarily
run with the same Annex state as CommandPerform. While its docs already
said it should avoid modifying Annex state, I audited all the
CommandStart code as part of the conversion. (Note that CommandSeek
already sometimes runs with a different Annex state, and that has not been
a source of any problems, so I am not too worried that this change will
lead to breakage going forward.)
The only modification of Annex state I found was it calling
allowMessages in some Commands that default to noMessages. Dealt with
that by adding a startCustomOutput and a startingUsualMessages.
This lets a command start with noMessages and then select the output it
wants for each CommandStart.
One bit of breakage: onlyActionOn has been removed from commands that used it.
The plan is that, since a StartMessage contains an ActionItem,
when a Key can be extracted from that, the parallel job runner can
run onlyActionOn' automatically. Then commands won't need to worry about
this detail. Future work.
Otherwise, this was a fairly straightforward process of making each
CommandStart compile again. Hopefully other behavior changes were mostly
avoided.
In a few cases, a command had a CommandStart that called a CommandPerform
that then called showStart multiple times. I have collapsed those
down to a single start action. The main command to perhaps suffer from it
is Command.Direct, which used to show a start for each file, and no
longer does.
Another minor behavior change is that some commands used showStart
before, but had an associated file and a Key available, so were changed
to ShowStart with an ActionItemAssociatedFile. That will not change the
normal output or behavior, but --json output will now include the key.
This should not break it for anyone using a real json parser.
2019-06-06 19:42:30 +00:00
|
|
|
cleanupRemote remote (Just b, _) =
|
2020-09-14 20:49:33 +00:00
|
|
|
starting "cleanup" ai si $
|
make CommandStart return a StartMessage
The goal is to be able to run CommandStart in the main thread when -J is
used, rather than unncessarily passing it off to a worker thread, which
incurs overhead that is signficant when the CommandStart is going to
quickly decide to stop.
To do that, the message it displays needs to be displayed in the worker
thread, after the CommandStart has run.
Also, the change will mean that CommandStart will no longer necessarily
run with the same Annex state as CommandPerform. While its docs already
said it should avoid modifying Annex state, I audited all the
CommandStart code as part of the conversion. (Note that CommandSeek
already sometimes runs with a different Annex state, and that has not been
a source of any problems, so I am not too worried that this change will
lead to breakage going forward.)
The only modification of Annex state I found was it calling
allowMessages in some Commands that default to noMessages. Dealt with
that by adding a startCustomOutput and a startingUsualMessages.
This lets a command start with noMessages and then select the output it
wants for each CommandStart.
One bit of breakage: onlyActionOn has been removed from commands that used it.
The plan is that, since a StartMessage contains an ActionItem,
when a Key can be extracted from that, the parallel job runner can
run onlyActionOn' automatically. Then commands won't need to worry about
this detail. Future work.
Otherwise, this was a fairly straightforward process of making each
CommandStart compile again. Hopefully other behavior changes were mostly
avoided.
In a few cases, a command had a CommandStart that called a CommandPerform
that then called showStart multiple times. I have collapsed those
down to a single start action. The main command to perhaps suffer from it
is Command.Direct, which used to show a start for each file, and no
longer does.
Another minor behavior change is that some commands used showStart
before, but had an associated file and a Key available, so were changed
to ShowStart with an ActionItemAssociatedFile. That will not change the
normal output or behavior, but --json output will now include the key.
This should not break it for anyone using a real json parser.
2019-06-06 19:42:30 +00:00
|
|
|
next $ inRepo $ Git.Command.runBool
|
2017-09-28 18:14:07 +00:00
|
|
|
[ Param "push"
|
|
|
|
, Param "--quiet"
|
|
|
|
, Param "--delete"
|
|
|
|
, Param $ Remote.name remote
|
|
|
|
, Param $ Git.fromRef $ syncBranch b
|
|
|
|
, Param $ Git.fromRef $ syncBranch $
|
|
|
|
Git.Ref.base $ Annex.Branch.name
|
|
|
|
]
|
2020-09-14 20:49:33 +00:00
|
|
|
where
|
|
|
|
ai = ActionItemOther (Just (Remote.name remote))
|
|
|
|
si = SeekInput []
|
|
|
|
|
2020-02-18 16:29:31 +00:00
|
|
|
shouldSyncContent :: SyncOptions -> Annex Bool
|
|
|
|
shouldSyncContent o
|
|
|
|
| noContentOption o = pure False
|
|
|
|
| contentOption o || not (null (contentOfOption o)) = pure True
|
|
|
|
| otherwise = getGitConfigVal annexSyncContent <||> onlyAnnex o
|
sync --only-annex and annex.synconlyannex
* Added sync --only-annex, which syncs the git-annex branch and annexed
content but leaves managing the other git branches up to you.
* Added annex.synconlyannex git config setting, which can also be set with
git-annex config to configure sync in all clones of the repo.
Use case is then the user has their own git workflow, and wants to use
git-annex without disrupting that, so they sync --only-annex to get the
git-annex stuff in sync in addition to their usual git workflow.
When annex.synconlyannex is set, --not-only-annex can be used to override
it.
It's not entirely clear what --only-annex --commit or --only-annex
--push should do, and I left that combination not documented because I
don't know if I might want to change the current behavior, which is that
such options do not override the --only-annex. My gut feeling is that
there is no good reasons to use such combinations; if you want to use
your own git workflow, you'll be doing your own committing and pulling
and pushing.
A subtle question is, how should import/export special remotes be handled?
Importing updates their remote tracking branch and merges it into master.
If --only-annex prevented that git branch stuff, then it would prevent
exporting to the special remote, in the case where it has changes that
were not imported yet, because there would be a unresolved conflict.
I decided that it's best to treat the fact that there's a remote tracking
branch for import/export as an implementation detail in this case. The more
important thing is that an import/export special remote is entirely annexed
content, and so it makes a lot of sense that --only-annex will still sync
with it.
2020-02-17 19:19:58 +00:00
|
|
|
|
|
|
|
notOnlyAnnex :: SyncOptions -> Annex Bool
|
|
|
|
notOnlyAnnex o = not <$> onlyAnnex o
|
|
|
|
|
|
|
|
onlyAnnex :: SyncOptions -> Annex Bool
|
2020-02-18 16:29:31 +00:00
|
|
|
onlyAnnex o
|
|
|
|
| notOnlyAnnexOption o = pure False
|
|
|
|
| onlyAnnexOption o = pure True
|
|
|
|
| otherwise = getGitConfigVal annexSyncOnlyAnnex
|
2020-12-23 16:10:39 +00:00
|
|
|
|
|
|
|
isExport :: Remote -> Bool
|
|
|
|
isExport = exportTree . Remote.config
|
|
|
|
|
|
|
|
isImport :: Remote -> Bool
|
|
|
|
isImport = importTree . Remote.config
|
|
|
|
|
|
|
|
isThirdPartyPopulated :: Remote -> Bool
|
|
|
|
isThirdPartyPopulated = Remote.thirdPartyPopulated . Remote.remotetype
|