2010-11-27 21:09:22 +00:00
|
|
|
{- git-annex command
|
|
|
|
-
|
2015-01-21 16:50:09 +00:00
|
|
|
- Copyright 2010 Joey Hess <id@joeyh.name>
|
2010-11-27 21:09:22 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
|
|
|
module Command.Copy where
|
|
|
|
|
|
|
|
import Command
|
|
|
|
import qualified Command.Move
|
2012-01-06 08:02:35 +00:00
|
|
|
import qualified Remote
|
2012-10-08 20:06:56 +00:00
|
|
|
import Annex.Wanted
|
2015-04-30 18:02:56 +00:00
|
|
|
import Annex.NumCopies
|
2010-11-27 21:09:22 +00:00
|
|
|
|
2015-07-08 16:33:27 +00:00
|
|
|
cmd :: Command
|
2018-02-19 18:28:17 +00:00
|
|
|
cmd = withGlobalOptions [jobsOption, jsonOptions, jsonProgressOption, annexedMatchingOptions] $
|
2015-07-30 17:33:35 +00:00
|
|
|
command "copy" SectionCommon
|
|
|
|
"copy content of files to/from another repository"
|
|
|
|
paramPaths (seek <--< optParser)
|
2015-07-09 19:23:14 +00:00
|
|
|
|
|
|
|
data CopyOptions = CopyOptions
|
2018-04-09 18:38:46 +00:00
|
|
|
{ copyFiles :: CmdParams
|
|
|
|
, fromToOptions :: FromToHereOptions
|
|
|
|
, keyOptions :: Maybe KeyOptions
|
2015-07-09 19:23:14 +00:00
|
|
|
, autoMode :: Bool
|
2018-04-09 18:38:46 +00:00
|
|
|
, batchOption :: BatchMode
|
2015-07-09 19:23:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
optParser :: CmdParamsDesc -> Parser CopyOptions
|
|
|
|
optParser desc = CopyOptions
|
2018-04-09 18:38:46 +00:00
|
|
|
<$> cmdParams desc
|
|
|
|
<*> parseFromToHereOptions
|
|
|
|
<*> optional (parseKeyOptions <|> parseFailedTransfersOption)
|
2015-07-09 19:23:14 +00:00
|
|
|
<*> parseAutoOption
|
2018-04-09 18:38:46 +00:00
|
|
|
<*> parseBatchOption
|
2015-07-09 19:23:14 +00:00
|
|
|
|
|
|
|
instance DeferredParseClass CopyOptions where
|
|
|
|
finishParse v = CopyOptions
|
2018-04-09 18:38:46 +00:00
|
|
|
<$> pure (copyFiles v)
|
|
|
|
<*> finishParse (fromToOptions v)
|
|
|
|
<*> pure (keyOptions v)
|
2015-07-09 19:23:14 +00:00
|
|
|
<*> pure (autoMode v)
|
2018-04-09 18:38:46 +00:00
|
|
|
<*> pure (batchOption v)
|
2015-07-09 19:23:14 +00:00
|
|
|
|
|
|
|
seek :: CopyOptions -> CommandSeek
|
2017-08-15 16:39:10 +00:00
|
|
|
seek o = allowConcurrentOutput $ do
|
|
|
|
let go = whenAnnexed $ start o
|
2018-04-09 18:38:46 +00:00
|
|
|
case batchOption o of
|
make --batch honor matching options
When --batch is used with matching options like --in, --metadata, etc, only
operate on the provided files when they match those options. Otherwise, a
blank line is output in the batch protocol.
Affected commands: find, add, whereis, drop, copy, move, get
In the case of find, the documentation for --batch already said it honored
the matching options. The docs for the rest didn't, but it makes sense to
have them honor them. While this is a behavior change, why specify the
matching options with --batch if you didn't want them to apply?
Note that the batch output for all of the affected commands could
already output a blank line in other cases, so batch users should
already be prepared to deal with it.
git-annex metadata didn't seem worth making support the matching options,
since all it does is output metadata or set metadata, the use cases for
using it in combination with the martching options seem small. Made it
refuse to run when they're combined, leaving open the possibility for later
support if a use case develops.
This commit was sponsored by Brett Eisenberg on Patreon.
2018-08-08 16:03:30 +00:00
|
|
|
Batch -> batchFilesMatching go
|
2017-08-15 16:39:10 +00:00
|
|
|
NoBatch -> withKeyOptions
|
2018-04-09 18:38:46 +00:00
|
|
|
(keyOptions o) (autoMode o)
|
2018-04-09 20:09:00 +00:00
|
|
|
(Command.Move.startKey (fromToOptions o) Command.Move.RemoveNever)
|
2017-08-15 16:39:10 +00:00
|
|
|
(withFilesInGit go)
|
2018-04-09 18:38:46 +00:00
|
|
|
=<< workTreeItems (copyFiles o)
|
2011-09-15 19:27:45 +00:00
|
|
|
|
2012-10-08 20:06:56 +00:00
|
|
|
{- A copy is just a move that does not delete the source file.
|
2015-03-25 21:06:14 +00:00
|
|
|
- However, auto mode avoids unnecessary copies, and avoids getting or
|
2012-10-08 20:06:56 +00:00
|
|
|
- sending non-preferred content. -}
|
2015-07-09 19:23:14 +00:00
|
|
|
start :: CopyOptions -> FilePath -> Key -> CommandStart
|
|
|
|
start o file key = stopUnless shouldCopy $
|
2018-04-09 20:09:00 +00:00
|
|
|
Command.Move.start (fromToOptions o) Command.Move.RemoveNever file key
|
2012-11-12 05:05:04 +00:00
|
|
|
where
|
2015-03-25 21:06:14 +00:00
|
|
|
shouldCopy
|
2015-07-09 19:23:14 +00:00
|
|
|
| autoMode o = want <||> numCopiesCheck file key (<)
|
2015-03-25 21:06:14 +00:00
|
|
|
| otherwise = return True
|
2018-04-09 18:38:46 +00:00
|
|
|
want = case fromToOptions o of
|
move --to=here
* move --to=here moves from all reachable remotes to the local repository.
The output of move --from remote is changed slightly, when the remote and
local both have the content. It used to say:
move foo ok
Now:
move foo (from theremote...) ok
That was done so that, when move --to=here is used and the content is
locally present and also in several remotes, it's clear which remotes the
content gets dropped from.
Note that move --to=here will report an error if a non-reachable remote
contains the file, even if the local repository also contains the file. I
think that's reasonable; the user may be intending to move all other copies
of the file from remotes.
OTOH, if a copy of the file is believed to be present in some repository
that is not a configured remote, move --to=here does not report an error.
So a little bit inconsistent, but erroring in this case feels wrong.
copy --to=here came along for free, but it's basically the same behavior as
git-annex get, and probably with not as good messages in edge cases
(especially on failure), so I've not documented it.
This commit was sponsored by Anthony DeRobertis on Patreon.
2017-05-31 20:57:27 +00:00
|
|
|
Right (ToRemote dest) ->
|
|
|
|
(Remote.uuid <$> getParsed dest) >>= checkwantsend
|
|
|
|
Right (FromRemote _) -> checkwantget
|
2018-04-09 18:38:46 +00:00
|
|
|
Left ToHere -> checkwantget
|
move --to=here
* move --to=here moves from all reachable remotes to the local repository.
The output of move --from remote is changed slightly, when the remote and
local both have the content. It used to say:
move foo ok
Now:
move foo (from theremote...) ok
That was done so that, when move --to=here is used and the content is
locally present and also in several remotes, it's clear which remotes the
content gets dropped from.
Note that move --to=here will report an error if a non-reachable remote
contains the file, even if the local repository also contains the file. I
think that's reasonable; the user may be intending to move all other copies
of the file from remotes.
OTOH, if a copy of the file is believed to be present in some repository
that is not a configured remote, move --to=here does not report an error.
So a little bit inconsistent, but erroring in this case feels wrong.
copy --to=here came along for free, but it's basically the same behavior as
git-annex get, and probably with not as good messages in edge cases
(especially on failure), so I've not documented it.
This commit was sponsored by Anthony DeRobertis on Patreon.
2017-05-31 20:57:27 +00:00
|
|
|
|
|
|
|
checkwantsend = wantSend False (Just key) (AssociatedFile (Just file))
|
|
|
|
checkwantget = wantGet False (Just key) (AssociatedFile (Just file))
|