2015-05-06 17:44:53 +00:00
|
|
|
{- git-annex batch commands
|
|
|
|
-
|
2020-07-22 18:23:28 +00:00
|
|
|
- Copyright 2015-2020 Joey Hess <id@joeyh.name>
|
2015-05-06 17:44:53 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2015-05-06 17:44:53 +00:00
|
|
|
-}
|
|
|
|
|
|
|
|
module CmdLine.Batch where
|
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
import qualified Annex
|
2016-01-20 20:36:33 +00:00
|
|
|
import Types.Command
|
|
|
|
import CmdLine.Action
|
|
|
|
import CmdLine.GitAnnex.Options
|
2020-07-22 18:23:28 +00:00
|
|
|
import CmdLine.Seek
|
2016-01-20 20:36:33 +00:00
|
|
|
import Options.Applicative
|
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
|
|
|
import Limit
|
|
|
|
import Types.FileMatcher
|
2020-04-09 17:54:43 +00:00
|
|
|
import Annex.BranchState
|
2020-07-22 18:23:28 +00:00
|
|
|
import Annex.WorkTree
|
|
|
|
import Annex.Content
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
import Annex.Concurrent
|
|
|
|
import Types.Concurrency
|
2015-05-06 17:44:53 +00:00
|
|
|
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
data BatchMode = Batch BatchFormat | NoBatch
|
|
|
|
|
|
|
|
data BatchFormat = BatchLine | BatchNull
|
2015-07-12 00:43:45 +00:00
|
|
|
|
2015-12-21 16:57:13 +00:00
|
|
|
parseBatchOption :: Parser BatchMode
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
parseBatchOption = go
|
|
|
|
<$> switch
|
|
|
|
( long "batch"
|
|
|
|
<> help "enable batch mode"
|
|
|
|
)
|
|
|
|
<*> switch
|
|
|
|
( short 'z'
|
|
|
|
<> help "null delimited batch input"
|
|
|
|
)
|
|
|
|
where
|
|
|
|
go True False = Batch BatchLine
|
|
|
|
go True True = Batch BatchNull
|
|
|
|
go False _ = NoBatch
|
2015-07-12 00:43:45 +00:00
|
|
|
|
2015-12-21 16:57:13 +00:00
|
|
|
-- A batchable command can run in batch mode, or not.
|
2015-05-06 17:44:53 +00:00
|
|
|
-- In batch mode, one line at a time is read, parsed, and a reply output to
|
|
|
|
-- stdout. In non batch mode, the command's parameters are parsed and
|
|
|
|
-- a reply output for each.
|
2020-09-16 14:18:36 +00:00
|
|
|
--
|
|
|
|
-- Note that the actions are not run concurrently.
|
2020-09-14 20:49:33 +00:00
|
|
|
batchable :: (opts -> SeekInput -> String -> Annex Bool) -> Parser opts -> CmdParamsDesc -> CommandParser
|
2015-07-12 00:43:45 +00:00
|
|
|
batchable handler parser paramdesc = batchseeker <$> batchparser
|
2015-05-06 17:44:53 +00:00
|
|
|
where
|
2015-07-12 00:43:45 +00:00
|
|
|
batchparser = (,,)
|
|
|
|
<$> parser
|
2015-12-21 16:57:13 +00:00
|
|
|
<*> parseBatchOption
|
2015-07-12 00:43:45 +00:00
|
|
|
<*> cmdParams paramdesc
|
|
|
|
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchseeker (opts, NoBatch, params) =
|
2020-09-14 20:49:33 +00:00
|
|
|
mapM_ (\p -> go NoBatch opts (SeekInput [p], p)) params
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchseeker (opts, batchmode@(Batch fmt), _) =
|
2020-04-15 20:04:05 +00:00
|
|
|
batchInput fmt (pure . Right) (go batchmode opts)
|
2015-07-12 00:43:45 +00:00
|
|
|
|
2020-09-14 20:49:33 +00:00
|
|
|
go batchmode opts (si, p) =
|
|
|
|
unlessM (handler opts si p) $
|
2015-07-12 00:43:45 +00:00
|
|
|
batchBadInput batchmode
|
2015-05-06 17:44:53 +00:00
|
|
|
|
|
|
|
-- bad input is indicated by an empty line in batch mode. In non batch
|
|
|
|
-- mode, exit on bad input.
|
|
|
|
batchBadInput :: BatchMode -> Annex ()
|
|
|
|
batchBadInput NoBatch = liftIO exitFailure
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchBadInput (Batch _) = liftIO $ putStrLn ""
|
2015-12-21 16:57:13 +00:00
|
|
|
|
2020-04-15 20:04:05 +00:00
|
|
|
-- Reads lines of batch mode input, runs a parser, and passes the result
|
|
|
|
-- to the action.
|
|
|
|
--
|
|
|
|
-- Note that if the batch input includes a worktree filename, it should
|
|
|
|
-- be converted to relative. Normally, filename parameters are passed
|
|
|
|
-- through git ls-files, which makes them relative, but batch mode does
|
|
|
|
-- not use that, and absolute worktree files are likely to cause breakage.
|
2020-09-14 20:49:33 +00:00
|
|
|
batchInput :: BatchFormat -> (String -> Annex (Either String v)) -> ((SeekInput, v) -> Annex ()) -> Annex ()
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchInput fmt parser a = go =<< batchLines fmt
|
2015-12-22 16:20:39 +00:00
|
|
|
where
|
2016-12-13 19:35:04 +00:00
|
|
|
go [] = return ()
|
|
|
|
go (l:rest) = do
|
2020-09-14 20:49:33 +00:00
|
|
|
either parseerr (\v -> a (SeekInput [l], v)) =<< parser l
|
2016-12-13 19:35:04 +00:00
|
|
|
go rest
|
2016-11-16 01:29:54 +00:00
|
|
|
parseerr s = giveup $ "Batch input parse failure: " ++ s
|
2016-01-19 21:46:46 +00:00
|
|
|
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchLines :: BatchFormat -> Annex [String]
|
2020-04-09 17:54:43 +00:00
|
|
|
batchLines fmt = do
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
checkBatchConcurrency
|
2020-07-06 16:09:53 +00:00
|
|
|
enableInteractiveBranchAccess
|
2020-04-09 17:54:43 +00:00
|
|
|
liftIO $ splitter <$> getContents
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
where
|
|
|
|
splitter = case fmt of
|
|
|
|
BatchLine -> lines
|
|
|
|
BatchNull -> splitc '\0'
|
2016-12-13 19:35:04 +00:00
|
|
|
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
-- When concurrency is enabled at the command line, it is used in batch
|
|
|
|
-- mode. But, if it's only set in git config, don't use it, because the
|
|
|
|
-- program using batch mode may not expect interleaved output.
|
|
|
|
checkBatchConcurrency :: Annex ()
|
|
|
|
checkBatchConcurrency = Annex.getState Annex.concurrency >>= \case
|
|
|
|
ConcurrencyCmdLine _ -> noop
|
|
|
|
ConcurrencyGitConfig _ ->
|
|
|
|
setConcurrency (ConcurrencyGitConfig (Concurrent 1))
|
|
|
|
|
2020-09-16 14:53:16 +00:00
|
|
|
batchCommandAction :: CommandStart -> Annex ()
|
support --batch -J
--batch combined with -J now runs batch requests concurrently for many
commands. Before, the combination was accepted, but did not enable
concurrency. Since the output of batch requests can be in any order, --json
with the new "input" field is recommended to be used, to determine which
batch request each response corresponds to.
If --json is not used, batch mode still runs concurrently, using the usual
concurrent-output. That will not be very useful for most batch mode users,
probably, but who knows.
If a program was using --batch -J before, and was parsing non-json output,
this could break it. But, it was relying on git-annex not supporting
concurrency despite it being enabled, so it should have expected concurrent
output. So, I think that's ok.
annex.jobs does not enable concurrency in --batch mode, because that would
confuse programs that use --batch but don't expect concurrency.
2020-09-16 15:58:19 +00:00
|
|
|
batchCommandAction = commandAction . batchCommandStart
|
2020-09-16 14:53:16 +00:00
|
|
|
|
2016-01-19 21:46:46 +00:00
|
|
|
-- The batch mode user expects to read a line of output, and it's up to the
|
|
|
|
-- CommandStart to generate that output as it succeeds or fails to do its
|
|
|
|
-- job. However, if it stops without doing anything, it won't generate
|
2020-09-16 14:53:16 +00:00
|
|
|
-- any output. This modifies it so in that case, an empty line is printed.
|
|
|
|
batchCommandStart :: CommandStart -> CommandStart
|
|
|
|
batchCommandStart a = a >>= \case
|
|
|
|
Just v -> return (Just v)
|
|
|
|
Nothing -> do
|
|
|
|
batchBadInput (Batch BatchLine)
|
|
|
|
return Nothing
|
2016-01-20 16:46:00 +00:00
|
|
|
|
|
|
|
-- Reads lines of batch input and passes the filepaths to a CommandStart
|
|
|
|
-- to handle them.
|
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
|
|
|
--
|
2020-09-16 14:18:36 +00:00
|
|
|
-- Absolute filepaths are converted to relative, because in non-batch
|
|
|
|
-- mode, that is done when CmdLine.Seek uses git ls-files.
|
2020-04-15 20:04:05 +00:00
|
|
|
--
|
2020-09-16 14:18:36 +00:00
|
|
|
-- File matching options are checked, and non-matching files skipped.
|
2020-09-14 20:49:33 +00:00
|
|
|
batchFilesMatching :: BatchFormat -> ((SeekInput, RawFilePath) -> CommandStart) -> Annex ()
|
added -z
Added -z option to git-annex commands that use --batch, useful for
supporting filenames containing newlines.
It only controls input to --batch, the output will still be line delimited
unless --json or etc is used to get some other output. While git often
makes -z affect both input and output, I don't like trying them together,
and making it affect output would have been a significant complication,
and also git-annex output is generally not intended to be machine parsed,
unless using --json or a format option.
Commands that take pairs like "file key" still separate them with a space
in --batch mode. All such commands take care to support filenames with
spaces when parsing that, so there was no need to change it, and it would
have needed significant changes to the batch machinery to separate tose
with a null.
To make fromkey and registerurl support -z, I had to give them a --batch
option. The implicit batch mode they enter when not provided with input
parameters does not support -z as that would have complicated option
parsing. Seemed better to move these toward using the same --batch as
everything else, though the implicit batch mode can still be used.
This commit was sponsored by Ole-Morten Duesund on Patreon.
2018-09-20 20:09:21 +00:00
|
|
|
batchFilesMatching fmt a = do
|
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
|
|
|
matcher <- getMatcher
|
2020-09-16 14:18:36 +00:00
|
|
|
go $ \si f ->
|
2019-12-09 17:49:05 +00:00
|
|
|
let f' = toRawFilePath f
|
2020-09-28 15:08:30 +00:00
|
|
|
in ifM (matcher $ MatchingFile $ FileInfo (Just f') f')
|
2020-09-14 20:49:33 +00:00
|
|
|
( a (si, f')
|
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
|
|
|
, return Nothing
|
|
|
|
)
|
2020-09-16 14:18:36 +00:00
|
|
|
where
|
|
|
|
go a' = batchInput fmt
|
|
|
|
(Right <$$> liftIO . relPathCwdToFile)
|
|
|
|
(batchCommandAction . uncurry a')
|
2020-07-22 18:23:28 +00:00
|
|
|
|
|
|
|
batchAnnexedFilesMatching :: BatchFormat -> AnnexedFileSeeker -> Annex ()
|
2020-09-14 20:49:33 +00:00
|
|
|
batchAnnexedFilesMatching fmt seeker = batchFilesMatching fmt $ \(si, bf) ->
|
|
|
|
flip whenAnnexed bf $ \f k ->
|
|
|
|
case checkContentPresent seeker of
|
|
|
|
Just v -> do
|
|
|
|
present <- inAnnex k
|
|
|
|
if present == v
|
|
|
|
then startAction seeker si f k
|
|
|
|
else return Nothing
|
|
|
|
Nothing -> startAction seeker si f k
|