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>
|
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
|
|
|
- Copyright 2011-2020 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,
|
|
|
|
syncBranch,
|
2018-10-20 18:12:04 +00:00
|
|
|
updateBranches,
|
2017-09-20 18:37:20 +00:00
|
|
|
seekExportContent,
|
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
|
2017-02-17 19:21:39 +00:00
|
|
|
import Config.Files
|
2014-01-19 21:35:36 +00:00
|
|
|
import Annex.Wanted
|
|
|
|
import Annex.Content
|
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
|
2014-03-04 20:26:15 +00:00
|
|
|
import Annex.AutoMerge
|
2016-02-29 19:23:08 +00:00
|
|
|
import Annex.AdjustedBranch
|
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
|
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
|
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
|
2011-12-10 00:27:22 +00:00
|
|
|
|
2015-07-08 16:33:27 +00:00
|
|
|
cmd :: Command
|
2015-08-14 17:49:55 +00:00
|
|
|
cmd = withGlobalOptions [jobsOption] $
|
|
|
|
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
|
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
|
|
|
|
}
|
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
|
|
|
)
|
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)
|
|
|
|
<*> liftIO (mapM absPath (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)
|
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
|
use fine-grained WorkerStages when transferring and verifying
This means that Command.Move and Command.Get don't need to
manually set the stage, and is a lot cleaner conceptually.
Also, this makes Command.Sync.syncFile use the worker pool better.
In the scenario where it first downloads content and then uploads it to
some other remotes, it will start in TransferStage, then enter VerifyStage
and then go back to TransferStage for each transfer to the remotes.
Before, it entered CleanupStage after the download, and stayed in it for
the upload, so too many transfer jobs could run at the same time.
Note that, in Remote.Git, it uses runTransfer and also verifyKeyContent
inside onLocal. That has a Annex state for the remote, with no worker pool.
So the resulting calls to enteringStage won't block in there.
While Remote.Git.copyToRemote does do checksum verification, I
realized that should not use a verification slot in the WorkerPool
to do it. Because, it's reading back from eg, a removable disk to checksum.
That will contend with other writes to that disk. It's best to treat
that checksum verification as just part of the transer. So, removed the todo
item about that, as there's nothing needing to be done.
2019-06-19 17:09:26 +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-02-19 17:58:26 +00:00
|
|
|
let gitremotes = filter (Remote.gitSyncableRemoteType . Remote.remotetype) remotes
|
2018-12-18 17:58:12 +00:00
|
|
|
dataremotes <- filter (\r -> Remote.uuid r /= NoUUID)
|
2017-08-17 16:26:14 +00:00
|
|
|
<$> filterM (not <$$> liftIO . getDynamicConfig . remoteAnnexIgnore . Remote.gitconfig) remotes
|
2019-03-11 18:09:46 +00:00
|
|
|
let (exportremotes, keyvalueremotes) = partition (exportTree . Remote.config) dataremotes
|
2019-03-09 17:57:49 +00:00
|
|
|
let importremotes = filter (importTree . Remote.config) dataremotes
|
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
|
|
|
|
-- 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 ]
|
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
|
|
|
, [ withbranch (mergeLocal mergeConfig o) ]
|
2017-09-28 18:14:07 +00:00
|
|
|
, map (withbranch . pullRemote o mergeConfig) gitremotes
|
|
|
|
, [ mergeAnnex ]
|
2017-09-19 18:20:47 +00:00
|
|
|
]
|
2019-03-09 17:57:49 +00:00
|
|
|
|
2020-02-18 16:29:31 +00:00
|
|
|
whenM (shouldSyncContent o) $ do
|
2019-03-09 17:57:49 +00:00
|
|
|
mapM_ (withbranch . importRemote o mergeConfig) importremotes
|
|
|
|
|
|
|
|
-- 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 $
|
|
|
|
seekExportContent (Just o) exportremotes
|
|
|
|
syncedcontent <- withbranch $
|
2019-03-11 18:09:46 +00:00
|
|
|
seekSyncContent o keyvalueremotes
|
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
|
|
|
|
[ map (withbranch . pullRemote o mergeConfig) gitremotes
|
|
|
|
, [ 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
|
|
|
|
2016-04-22 18:35:48 +00:00
|
|
|
mergeConfig :: [Git.Merge.MergeConfig]
|
2016-11-15 22:26:17 +00:00
|
|
|
mergeConfig =
|
|
|
|
[ Git.Merge.MergeNonInteractive
|
|
|
|
-- In several situations, unrelated histories should be merged
|
2019-03-09 17:57:49 +00:00
|
|
|
-- together. This includes pairing in the assistant, merging
|
|
|
|
-- from a remote into a newly created direct mode repo,
|
|
|
|
-- and an initial merge from an import from a special remote.
|
2016-11-16 20:03:23 +00:00
|
|
|
-- (Once direct mode is removed, this could be changed, so only
|
2019-03-09 17:57:49 +00:00
|
|
|
-- the assistant and import from special remotes use it.)
|
2016-11-15 22:26:17 +00:00
|
|
|
, Git.Merge.MergeUnrelatedHistories
|
|
|
|
]
|
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
|
|
|
|
merge currbranch mergeconfig o commitmode tomerge = case currbranch of
|
2018-10-20 18:12:04 +00:00
|
|
|
(Just b, Just adj) -> mergeToAdjustedBranch tomerge (b, adj) mergeconfig canresolvemerge commitmode
|
2017-06-01 16:46:36 +00:00
|
|
|
(b, _) -> autoMergeFrom tomerge b mergeconfig canresolvemerge commitmode
|
|
|
|
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
|
|
|
canresolvemerge = if resolveMergeOverride o
|
|
|
|
then getGitConfigVal annexResolveMerge
|
|
|
|
else return False
|
2016-02-29 19:57:47 +00:00
|
|
|
|
2016-03-03 18:13:54 +00:00
|
|
|
syncBranch :: Git.Branch -> Git.Branch
|
2019-08-26 19:52:19 +00:00
|
|
|
syncBranch = Git.Ref.underBase "refs/heads/synced" . 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 =
|
|
|
|
ifM (Annex.getState Annex.fast) ( nub <$> pickfast , wanted )
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
2015-08-05 17:49:54 +00:00
|
|
|
pickfast = (++) <$> listed <*> (filterM good (fastest available))
|
2014-12-29 17:41:03 +00:00
|
|
|
|
2012-11-12 05:05:04 +00:00
|
|
|
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
|
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
|
|
|
commit o = stopUnless shouldcommit $ starting "commit" (ActionItemOther Nothing) $ 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
|
|
|
|
void $ inRepo $ Git.Branch.commitCommand Git.Branch.ManualCommit
|
|
|
|
[ 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
|
|
|
)
|
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
|
|
|
|
mergeLocal' mergeconfig o currbranch@(Just _, _) =
|
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
|
|
|
needMerge currbranch >>= \case
|
|
|
|
Nothing -> stop
|
|
|
|
Just syncbranch ->
|
|
|
|
starting "merge" (ActionItemOther (Just $ Git.Ref.describe syncbranch)) $
|
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
|
|
|
|
mergeLocal' _ _ (Nothing, madj) = do
|
2017-02-14 19:58:05 +00:00
|
|
|
b <- inRepo Git.Branch.currentUnsafe
|
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
|
|
|
needMerge (b, madj) >>= \case
|
|
|
|
Nothing -> stop
|
|
|
|
Just syncbranch ->
|
|
|
|
starting "merge" (ActionItemOther (Just $ Git.Ref.describe syncbranch)) $ do
|
|
|
|
warning $ "There are no commits yet in the currently checked out branch, so cannot merge any remote changes into it."
|
|
|
|
next $ return False
|
2017-02-14 19:58:05 +00:00
|
|
|
|
|
|
|
-- Returns the branch that should be merged, if any.
|
|
|
|
needMerge :: CurrBranch -> Annex (Maybe Git.Branch)
|
|
|
|
needMerge (Nothing, _) = return Nothing
|
2017-02-15 17:55:06 +00:00
|
|
|
needMerge (Just branch, madj) = ifM (allM id checks)
|
2017-02-14 19:58:05 +00:00
|
|
|
( return (Just syncbranch)
|
|
|
|
, return Nothing
|
|
|
|
)
|
|
|
|
where
|
|
|
|
checks =
|
|
|
|
[ not <$> isBareRepo
|
|
|
|
, inRepo (Git.Ref.exists syncbranch)
|
|
|
|
, inRepo (Git.Branch.changed branch' syncbranch)
|
|
|
|
]
|
|
|
|
syncbranch = syncBranch branch
|
2016-04-09 19:10:26 +00:00
|
|
|
branch' = maybe branch (adjBranch . originalToAdjusted branch) madj
|
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
|
|
|
|
-- to be updated to hide/expose files.
|
|
|
|
case madj of
|
|
|
|
Nothing -> noop
|
|
|
|
Just adj -> do
|
|
|
|
let origbranch = branch
|
|
|
|
propigateAdjustedCommits origbranch adj
|
|
|
|
when (adjustmentHidesFiles adj) $ do
|
|
|
|
showSideAction "updating adjusted branch"
|
|
|
|
let adjbranch = originalToAdjusted origbranch adj
|
|
|
|
unlessM (updateAdjustedBranch adj adjbranch origbranch) $
|
|
|
|
warning $ unwords [ "Updating adjusted branch failed." ]
|
|
|
|
|
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 =
|
2016-11-16 01:29:54 +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) $
|
|
|
|
starting "pull" (ActionItemOther (Just (Remote.name remote))) $ 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
|
|
|
|
inRepoWithSshOptionsTo repo (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
|
|
|
Git.Command.runBool $
|
2018-06-04 18:31:55 +00:00
|
|
|
[Param "fetch", Param $ Remote.name 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
|
|
|
++ 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)
|
2011-12-10 00:27:22 +00:00
|
|
|
|
2019-03-09 17:57:49 +00:00
|
|
|
importRemote :: SyncOptions -> [Git.Merge.MergeConfig] -> Remote -> CurrBranch -> CommandSeek
|
|
|
|
importRemote o mergeconfig remote currbranch
|
|
|
|
| not (pullOption o) || not wantpull = noop
|
|
|
|
| otherwise = case remoteAnnexTrackingBranch (Remote.gitconfig remote) of
|
|
|
|
Nothing -> noop
|
|
|
|
Just tb -> do
|
|
|
|
let (b, s) = separate (== ':') (Git.fromRef tb)
|
|
|
|
let branch = Git.Ref b
|
|
|
|
let subdir = if null s
|
|
|
|
then Nothing
|
2019-12-09 17:49:05 +00:00
|
|
|
else Just (asTopFilePath (toRawFilePath s))
|
2019-03-09 17:57:49 +00:00
|
|
|
Command.Import.seekRemote remote branch subdir
|
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 $ mergeRemote remote currbranch mergeconfig o
|
2019-03-09 17:57:49 +00:00
|
|
|
where
|
|
|
|
wantpull = remoteAnnexPull (Remote.gitconfig remote)
|
|
|
|
|
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 = []
|
2019-08-26 19:52:19 +00:00
|
|
|
branchlist (Just branch) = [fromAdjustedBranch 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) $
|
|
|
|
starting "push" (ActionItemOther (Just (Remote.name remote))) $ next $ do
|
|
|
|
repo <- Remote.getRepo remote
|
|
|
|
showOutput
|
|
|
|
ok <- inRepoWithSshOptionsTo repo gc $
|
|
|
|
pushBranch remote mainbranch
|
|
|
|
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
|
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
|
|
|
|
( liftIO $ do
|
|
|
|
p <- readProgramFile
|
|
|
|
boolSystem' p [Param "post-receive"]
|
2019-12-09 17:49:05 +00:00
|
|
|
(\cp -> cp { cwd = Just (fromRawFilePath wt) })
|
2018-06-05 17:03:42 +00:00
|
|
|
, return True
|
|
|
|
)
|
|
|
|
where
|
|
|
|
needemulation = Remote.Git.onLocal repo remote $
|
|
|
|
(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
|
|
|
-
|
|
|
|
- The sync push forces the update of the remote synced/git-annex branch.
|
|
|
|
- This is necessary if a transition has rewritten the git-annex branch.
|
|
|
|
- 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
|
|
|
-}
|
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
|
|
|
pushBranch :: Remote -> Maybe Git.Branch -> Git.Repo -> IO Bool
|
|
|
|
pushBranch remote mbranch 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
|
|
|
|
[ Just $ Git.Branch.forcePush $ refspec Annex.Branch.name
|
|
|
|
, (refspec . fromAdjustedBranch) <$> mbranch
|
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
|
|
|
|
[ Git.fromRef $ Git.Ref.base $ fromAdjustedBranch branch ]
|
|
|
|
(transcript, ok) <- processTranscript' p Nothing
|
|
|
|
when (not ok && not ("denyCurrentBranch" `isInfixOf` transcript)) $
|
|
|
|
hPutStr stderr transcript
|
2013-08-29 18:15:32 +00:00
|
|
|
pushparams branches =
|
2013-03-03 17:39:07 +00:00
|
|
|
[ Param "push"
|
|
|
|
, 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.)
|
|
|
|
-
|
|
|
|
- With --all, makes a second pass over all keys.
|
2015-06-16 22:38:12 +00:00
|
|
|
- This ensures that preferred content expressions that match on
|
|
|
|
- filenames work, even when in --all mode.
|
|
|
|
-
|
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
|
|
|
|
Just WantAllKeys -> Just <$> genBloomFilter (seekworktree mvar [])
|
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
|
|
|
|
l <- workTreeItems' (AllowHidden True) (contentOfOption o)
|
|
|
|
seekincludinghidden origbranch mvar l (const noop)
|
|
|
|
pure Nothing
|
|
|
|
_ -> do
|
2018-10-19 19:17:48 +00:00
|
|
|
l <- workTreeItems (contentOfOption o)
|
|
|
|
seekworktree mvar l (const noop)
|
|
|
|
pure Nothing
|
2015-07-09 23:03:21 +00:00
|
|
|
withKeyOptions' (keyOptions o) False
|
2018-10-19 21:51:25 +00:00
|
|
|
(return (gokey mvar bloom))
|
2015-07-09 23:03:21 +00:00
|
|
|
(const noop)
|
|
|
|
[]
|
2015-08-14 17:49:55 +00:00
|
|
|
finishCommandActions
|
2014-02-01 14:49:50 +00:00
|
|
|
liftIO $ not <$> isEmptyMVar mvar
|
2014-01-20 17:31:03 +00:00
|
|
|
where
|
2018-10-19 21:51:25 +00:00
|
|
|
seekworktree mvar l bloomfeeder =
|
|
|
|
seekHelper LsFiles.inRepo l
|
|
|
|
>>= gofiles bloomfeeder mvar
|
|
|
|
|
|
|
|
seekincludinghidden origbranch mvar l bloomfeeder =
|
|
|
|
seekHelper (LsFiles.inRepoOrBranch origbranch) l
|
|
|
|
>>= gofiles bloomfeeder mvar
|
|
|
|
|
|
|
|
gofiles bloomfeeder mvar = mapM_ $ \f ->
|
|
|
|
ifAnnexed f
|
|
|
|
(go (Right bloomfeeder) mvar (AssociatedFile (Just f)))
|
|
|
|
noop
|
|
|
|
|
|
|
|
gokey mvar bloom (k, _) = 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
|
|
|
|
-- Run syncFile as a command action so file transfers run
|
|
|
|
-- concurrently.
|
|
|
|
let ai = OnlyActionOn k (ActionItemKey k)
|
2019-06-12 18:11:23 +00:00
|
|
|
commandAction $ 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
|
|
|
|
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
|
2015-07-20 18:24:13 +00:00
|
|
|
putrs <- handleput lack
|
2014-01-20 17:31:03 +00:00
|
|
|
|
2014-02-03 02:46:55 +00:00
|
|
|
u <- getUUID
|
2018-12-18 17:58:12 +00:00
|
|
|
let locs' = concat [if inhere || got then [u] else [], putrs, locs]
|
2014-02-03 02:46:55 +00:00
|
|
|
|
2015-06-16 22:38:12 +00:00
|
|
|
-- A bloom filter is populated with all the keys 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 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.
|
2015-10-08 20:55:11 +00:00
|
|
|
handleDropsFrom locs' rs "unwanted" True k af []
|
|
|
|
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 []
|
|
|
|
)
|
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
|
|
|
get have = includeCommandAction $ starting "get" ai $
|
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
|
2015-06-16 19:07:03 +00:00
|
|
|
| otherwise = wantSend True (Just k) af (Remote.uuid r)
|
2015-07-20 18:24:13 +00:00
|
|
|
handleput lack = catMaybes <$> ifM (inAnnex k)
|
|
|
|
( forM lack $ \r ->
|
|
|
|
ifM (wantput r <&&> put r)
|
|
|
|
( return (Just (Remote.uuid r))
|
|
|
|
, return Nothing
|
|
|
|
)
|
2014-01-19 21:35:36 +00:00
|
|
|
, return []
|
|
|
|
)
|
2016-03-09 19:04:00 +00:00
|
|
|
put dest = includeCommandAction $
|
2019-06-06 16:53:24 +00:00
|
|
|
Command.Move.toStart' dest Command.Move.RemoveNever af k ai
|
|
|
|
|
|
|
|
ai = mkActionItem (k, af)
|
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
|
|
|
|
Nothing -> nontracking r db
|
|
|
|
Just b -> do
|
|
|
|
mtree <- inRepo $ Git.Ref.tree b
|
|
|
|
mtbcommitsha <- Command.Export.getExportCommit r b
|
|
|
|
case (mtree, mtbcommitsha) of
|
|
|
|
(Just tree, Just _) -> do
|
|
|
|
filteredtree <- Command.Export.filterPreferredContent r tree
|
|
|
|
Command.Export.changeExport r db filteredtree
|
|
|
|
Command.Export.fillExport r db filteredtree mtbcommitsha
|
|
|
|
_ -> nontracking r db
|
|
|
|
|
|
|
|
nontracking r db = do
|
2018-09-27 19:35:46 +00:00
|
|
|
exported <- getExport (Remote.uuid r)
|
|
|
|
maybe noop (warnnontracking r exported) currbranch
|
2019-05-20 15:54:55 +00:00
|
|
|
fillexport r db (exportedTreeishes exported) Nothing
|
2018-09-27 19:35:46 +00:00
|
|
|
|
|
|
|
warnnontracking r exported currb = inRepo (Git.Ref.tree currb) >>= \case
|
2019-01-30 16:36:30 +00:00
|
|
|
Just currt | not (any (== currt) (exportedTreeishes exported)) ->
|
2018-09-27 19:35:46 +00:00
|
|
|
showLongNote $ unwords
|
|
|
|
[ "Not updating export to " ++ Remote.name r
|
|
|
|
, "to reflect changes to the tree, because export"
|
|
|
|
, "tracking is not enabled. "
|
2019-03-01 20:08:18 +00:00
|
|
|
, "(Set " ++ gitconfig ++ " to enable it.)"
|
2018-09-27 19:35:46 +00:00
|
|
|
]
|
|
|
|
_ -> noop
|
2019-03-01 20:08:18 +00:00
|
|
|
where
|
2020-02-19 17:45:11 +00:00
|
|
|
gitconfig = show (remoteAnnexConfig r "tracking-branch")
|
2018-09-27 19:35:46 +00:00
|
|
|
|
2019-03-01 20:08:18 +00:00
|
|
|
fillexport _ _ [] _ = return False
|
2019-05-20 15:54:55 +00:00
|
|
|
fillexport r db (tree:[]) mtbcommitsha = do
|
|
|
|
let filteredtree = Command.Export.PreferredFiltered tree
|
|
|
|
Command.Export.fillExport r db filteredtree mtbcommitsha
|
2019-03-01 20:08:18 +00:00
|
|
|
fillexport 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
|
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
|
|
|
cleanupLocal (Just currb, _) =
|
|
|
|
starting "cleanup" (ActionItemOther (Just "local")) $
|
|
|
|
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
|
|
|
|
|
|
|
|
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, _) =
|
|
|
|
starting "cleanup" (ActionItemOther (Just (Remote.name remote))) $
|
|
|
|
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-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
|