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