2011-10-30 03:48:46 +00:00
|
|
|
{- git-annex command seeking
|
|
|
|
-
|
|
|
|
- These functions find appropriate files or other things based on
|
|
|
|
- the values a user passes to a command, and prepare actions operating
|
|
|
|
- on them.
|
|
|
|
-
|
2020-05-28 19:55:17 +00:00
|
|
|
- Copyright 2010-2020 Joey Hess <id@joeyh.name>
|
2011-10-30 03:48:46 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2011-10-30 03:48:46 +00:00
|
|
|
-}
|
|
|
|
|
2020-07-14 16:44:35 +00:00
|
|
|
{-# LANGUAGE TupleSections #-}
|
|
|
|
|
2014-01-26 20:25:55 +00:00
|
|
|
module CmdLine.Seek where
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2011-10-30 03:48:46 +00:00
|
|
|
import Types.Command
|
2013-05-25 03:07:26 +00:00
|
|
|
import Types.FileMatcher
|
2011-10-30 03:48:46 +00:00
|
|
|
import qualified Annex
|
|
|
|
import qualified Git
|
2012-10-04 23:56:32 +00:00
|
|
|
import qualified Git.Command
|
2011-10-30 03:48:46 +00:00
|
|
|
import qualified Git.LsFiles as LsFiles
|
2014-04-17 22:41:24 +00:00
|
|
|
import qualified Git.LsTree as LsTree
|
2020-07-10 19:11:14 +00:00
|
|
|
import qualified Git.Types as Git
|
2020-07-13 21:04:02 +00:00
|
|
|
import qualified Git.Ref
|
2014-04-17 22:41:24 +00:00
|
|
|
import Git.FilePath
|
2011-10-30 03:48:46 +00:00
|
|
|
import qualified Limit
|
2015-07-08 21:59:06 +00:00
|
|
|
import CmdLine.GitAnnex.Options
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
import Logs
|
2013-07-03 19:26:59 +00:00
|
|
|
import Logs.Unused
|
2016-08-03 16:37:12 +00:00
|
|
|
import Types.Transfer
|
|
|
|
import Logs.Transfer
|
|
|
|
import Remote.List
|
|
|
|
import qualified Remote
|
2013-08-22 17:57:07 +00:00
|
|
|
import Annex.CatFile
|
2020-07-13 18:09:08 +00:00
|
|
|
import Git.CatFile
|
2018-10-19 21:51:25 +00:00
|
|
|
import Annex.CurrentBranch
|
2015-06-02 18:20:38 +00:00
|
|
|
import Annex.Content
|
2020-07-10 17:54:52 +00:00
|
|
|
import Annex.Link
|
2018-09-12 19:20:34 +00:00
|
|
|
import Annex.InodeSentinal
|
2020-07-10 17:54:52 +00:00
|
|
|
import Annex.Concurrent
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
import qualified Annex.Branch
|
|
|
|
import qualified Annex.BranchState
|
2018-09-12 19:20:34 +00:00
|
|
|
import qualified Database.Keys
|
2019-12-06 19:37:12 +00:00
|
|
|
import qualified Utility.RawFilePath as R
|
2020-07-10 17:54:52 +00:00
|
|
|
import Utility.Tuple
|
2020-07-22 18:23:28 +00:00
|
|
|
import CmdLine.Action
|
2020-07-10 17:54:52 +00:00
|
|
|
|
|
|
|
import Control.Concurrent.Async
|
|
|
|
import System.Posix.Types
|
2011-11-08 19:34:10 +00:00
|
|
|
|
2020-07-13 21:04:02 +00:00
|
|
|
data AnnexedFileSeeker = AnnexedFileSeeker
|
2020-07-22 18:23:28 +00:00
|
|
|
{ startAction :: RawFilePath -> Key -> CommandStart
|
2020-07-13 21:04:02 +00:00
|
|
|
, checkContentPresent :: Maybe Bool
|
|
|
|
, usesLocationLog :: Bool
|
|
|
|
}
|
|
|
|
|
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
|
|
|
withFilesInGitAnnex :: WarnUnmatchWhen -> AnnexedFileSeeker -> WorkTreeItems -> CommandSeek
|
2020-07-10 18:17:35 +00:00
|
|
|
withFilesInGitAnnex ww a l = seekFilteredKeys a $
|
2020-07-10 17:54:52 +00:00
|
|
|
seekHelper fst3 ww LsFiles.inRepoDetails l
|
2011-10-30 03:48:46 +00:00
|
|
|
|
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
|
|
|
withFilesInGitAnnexNonRecursive :: WarnUnmatchWhen -> String -> AnnexedFileSeeker -> WorkTreeItems -> CommandSeek
|
|
|
|
withFilesInGitAnnexNonRecursive ww needforce a (WorkTreeItems l) = ifM (Annex.getState Annex.force)
|
|
|
|
( withFilesInGitAnnex ww a (WorkTreeItems l)
|
2017-10-16 18:10:03 +00:00
|
|
|
, if null l
|
2016-11-16 01:29:54 +00:00
|
|
|
then giveup needforce
|
2020-07-10 19:40:06 +00:00
|
|
|
else seekFilteredKeys a (getfiles [] l)
|
2015-02-10 20:06:53 +00:00
|
|
|
)
|
|
|
|
where
|
|
|
|
getfiles c [] = return (reverse c)
|
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
|
|
|
getfiles c (p:ps) = do
|
2020-05-28 19:55:17 +00:00
|
|
|
os <- seekOptions ww
|
2020-07-10 19:40:06 +00:00
|
|
|
(fs, cleanup) <- inRepo $ LsFiles.inRepoDetails os [toRawFilePath p]
|
2015-02-10 20:06:53 +00:00
|
|
|
case fs of
|
|
|
|
[f] -> do
|
|
|
|
void $ liftIO $ cleanup
|
|
|
|
getfiles (f:c) ps
|
|
|
|
[] -> do
|
|
|
|
void $ liftIO $ cleanup
|
|
|
|
getfiles c ps
|
2016-11-16 01:29:54 +00:00
|
|
|
_ -> giveup needforce
|
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
|
|
|
withFilesInGitAnnexNonRecursive _ _ _ NoWorkTreeItems = noop
|
2015-02-10 20:06:53 +00:00
|
|
|
|
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
|
|
|
withFilesNotInGit :: (RawFilePath -> CommandSeek) -> WorkTreeItems -> CommandSeek
|
|
|
|
withFilesNotInGit a (WorkTreeItems l) = go =<< seek
|
2012-11-11 04:51:07 +00:00
|
|
|
where
|
2019-12-26 20:24:40 +00:00
|
|
|
seek = do
|
2012-11-11 04:51:07 +00:00
|
|
|
force <- Annex.getState Annex.force
|
|
|
|
g <- gitRepo
|
2017-10-16 18:10:03 +00:00
|
|
|
liftIO $ Git.Command.leaveZombie
|
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
|
|
|
<$> LsFiles.notInRepo [] force l' g
|
2020-07-10 17:54:52 +00:00
|
|
|
go fs = seekFiltered a $
|
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
|
|
|
return $ concat $ segmentPaths id l' fs
|
|
|
|
l' = map toRawFilePath l
|
|
|
|
withFilesNotInGit _ NoWorkTreeItems = noop
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2019-11-26 19:27:22 +00:00
|
|
|
withPathContents :: ((FilePath, FilePath) -> CommandSeek) -> CmdParams -> CommandSeek
|
2015-02-06 19:58:06 +00:00
|
|
|
withPathContents a params = do
|
|
|
|
matcher <- Limit.getMatcher
|
2018-04-26 16:06:12 +00:00
|
|
|
forM_ params $ \p -> do
|
|
|
|
fs <- liftIO $ get p
|
2018-10-01 18:12:06 +00:00
|
|
|
forM fs $ \f ->
|
|
|
|
whenM (checkmatch matcher f) $
|
|
|
|
a f
|
2012-11-11 04:51:07 +00:00
|
|
|
where
|
|
|
|
get p = ifM (isDirectory <$> getFileStatus p)
|
2015-01-09 17:11:56 +00:00
|
|
|
( map (\f -> (f, makeRelative (parentDir p) f))
|
2013-12-18 19:05:29 +00:00
|
|
|
<$> dirContentsRecursiveSkipping (".git" `isSuffixOf`) True p
|
2012-11-11 04:51:07 +00:00
|
|
|
, return [(p, takeFileName p)]
|
|
|
|
)
|
2015-02-06 19:58:06 +00:00
|
|
|
checkmatch matcher (f, relf) = matcher $ MatchingFile $ FileInfo
|
2019-12-09 17:49:05 +00:00
|
|
|
{ currFile = toRawFilePath f
|
|
|
|
, matchFile = toRawFilePath relf
|
2015-02-06 19:58:06 +00:00
|
|
|
}
|
2012-05-31 23:47:18 +00:00
|
|
|
|
2018-10-01 18:12:06 +00:00
|
|
|
withWords :: ([String] -> CommandSeek) -> CmdParams -> CommandSeek
|
2020-07-10 17:54:52 +00:00
|
|
|
withWords a params = a params
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2018-10-01 18:12:06 +00:00
|
|
|
withStrings :: (String -> CommandSeek) -> CmdParams -> CommandSeek
|
2020-07-10 17:54:52 +00:00
|
|
|
withStrings a params = sequence_ $ map a params
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2018-10-01 18:12:06 +00:00
|
|
|
withPairs :: ((String, String) -> CommandSeek) -> CmdParams -> CommandSeek
|
2020-07-10 17:54:52 +00:00
|
|
|
withPairs a params = sequence_ $ map a $ pairs [] params
|
2012-11-11 04:51:07 +00:00
|
|
|
where
|
|
|
|
pairs c [] = reverse c
|
|
|
|
pairs c (x:y:xs) = pairs ((x,y):c) xs
|
2016-11-16 01:29:54 +00:00
|
|
|
pairs _ _ = giveup "expected pairs"
|
2012-02-16 20:36:35 +00:00
|
|
|
|
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
|
|
|
withFilesToBeCommitted :: (RawFilePath -> CommandSeek) -> WorkTreeItems -> CommandSeek
|
2020-07-10 17:54:52 +00:00
|
|
|
withFilesToBeCommitted a l = seekFiltered a $
|
|
|
|
seekHelper id WarnUnmatchWorkTreeItems (const LsFiles.stagedNotDeleted) l
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2019-08-30 17:54:57 +00:00
|
|
|
{- unlocked pointer files that are staged, and whose content has not been
|
2018-09-12 19:20:34 +00:00
|
|
|
- modified-}
|
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
|
|
|
withUnmodifiedUnlockedPointers :: WarnUnmatchWhen -> (RawFilePath -> CommandSeek) -> WorkTreeItems -> CommandSeek
|
2020-07-10 17:54:52 +00:00
|
|
|
withUnmodifiedUnlockedPointers ww a l = seekFiltered a unlockedfiles
|
2018-09-12 17:53:03 +00:00
|
|
|
where
|
2019-08-30 17:54:57 +00:00
|
|
|
unlockedfiles = filterM isUnmodifiedUnlocked
|
2020-07-10 17:54:52 +00:00
|
|
|
=<< seekHelper id ww (const LsFiles.typeChangedStaged) l
|
2018-09-12 17:53:03 +00:00
|
|
|
|
2019-11-25 20:18:19 +00:00
|
|
|
isUnmodifiedUnlocked :: RawFilePath -> Annex Bool
|
2019-08-30 17:54:57 +00:00
|
|
|
isUnmodifiedUnlocked f = catKeyFile f >>= \case
|
2018-09-12 19:20:34 +00:00
|
|
|
Nothing -> return False
|
2019-12-11 18:12:22 +00:00
|
|
|
Just k -> sameInodeCache f =<< Database.Keys.getInodeCaches k
|
2018-09-12 17:53:03 +00:00
|
|
|
|
2013-02-20 18:12:55 +00:00
|
|
|
{- Finds files that may be modified. -}
|
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
|
|
|
withFilesMaybeModified :: WarnUnmatchWhen -> (RawFilePath -> CommandSeek) -> WorkTreeItems -> CommandSeek
|
2020-07-10 17:54:52 +00:00
|
|
|
withFilesMaybeModified ww a params = seekFiltered a $
|
|
|
|
seekHelper id ww LsFiles.modified params
|
2013-02-20 18:12:55 +00:00
|
|
|
|
2018-10-01 18:12:06 +00:00
|
|
|
withKeys :: (Key -> CommandSeek) -> CmdParams -> CommandSeek
|
2020-07-10 17:54:52 +00:00
|
|
|
withKeys a l = sequence_ $ map (a . parse) l
|
2012-11-11 04:51:07 +00:00
|
|
|
where
|
2019-01-14 17:17:47 +00:00
|
|
|
parse p = fromMaybe (giveup "bad key") $ deserializeKey p
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2018-10-01 18:12:06 +00:00
|
|
|
withNothing :: CommandSeek -> CmdParams -> CommandSeek
|
|
|
|
withNothing a [] = a
|
2016-11-16 01:29:54 +00:00
|
|
|
withNothing _ _ = giveup "This command takes no parameters."
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2016-08-03 16:37:12 +00:00
|
|
|
{- Handles the --all, --branch, --unused, --failed, --key, and
|
|
|
|
- --incomplete options, which specify particular keys to run an
|
|
|
|
- action on.
|
2013-07-03 19:26:59 +00:00
|
|
|
-
|
2015-06-02 18:20:38 +00:00
|
|
|
- In a bare repo, --all is the default.
|
2013-07-03 19:26:59 +00:00
|
|
|
-
|
2015-06-02 18:20:38 +00:00
|
|
|
- Otherwise falls back to a regular CommandSeek action on
|
2018-10-01 18:12:06 +00:00
|
|
|
- whatever params were passed.
|
|
|
|
-}
|
2016-07-20 19:22:55 +00:00
|
|
|
withKeyOptions
|
|
|
|
:: Maybe KeyOptions
|
|
|
|
-> Bool
|
2020-07-24 16:05:28 +00:00
|
|
|
-> AnnexedFileSeeker
|
2018-10-01 18:12:06 +00:00
|
|
|
-> ((Key, ActionItem) -> CommandSeek)
|
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 -> CommandSeek)
|
|
|
|
-> WorkTreeItems
|
2016-07-20 19:22:55 +00:00
|
|
|
-> CommandSeek
|
2020-07-24 16:05:28 +00:00
|
|
|
withKeyOptions ko auto seeker keyaction = withKeyOptions' ko auto mkkeyaction
|
2015-06-16 20:50:03 +00:00
|
|
|
where
|
--branch, stage 1
Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and
whereis commands. This option makes git-annex operate on files that are
included in a specified branch (or other treeish).
The names of the files from the branch that are being operated on are not
displayed yet; only the keys. Displaying the filenames will need changes
to every affected command.
Also, note that --branch can be specified repeatedly. This is not really
documented, but seemed worth supporting, especially since we may later want
the ability to operate on all branches matching a refspec. However, when
operating on two branches that contain the same key, that key will be
operated on twice.
2016-07-20 16:05:22 +00:00
|
|
|
mkkeyaction = do
|
|
|
|
matcher <- Limit.getMatcher
|
2020-07-24 16:05:28 +00:00
|
|
|
return $ \v@(k, ai) -> checkseeker k $
|
support findred and --branch with file matching options
* findref: Support file matching options: --include, --exclude,
--want-get, --want-drop, --largerthan, --smallerthan, --accessedwithin
* Commands supporting --branch now apply file matching options --include,
--exclude, --want-get, --want-drop to filenames from the branch.
Previously, combining --branch with those would fail to match anything.
* add, import, findref: Support --time-limit.
This commit was sponsored by Jake Vosloo on Patreon.
2018-12-09 17:38:35 +00:00
|
|
|
let i = case ai of
|
2019-06-06 16:53:24 +00:00
|
|
|
ActionItemBranchFilePath (BranchFilePath _ topf) _ ->
|
2019-12-09 17:49:05 +00:00
|
|
|
MatchingKey k (AssociatedFile $ Just $ getTopFilePath topf)
|
support findred and --branch with file matching options
* findref: Support file matching options: --include, --exclude,
--want-get, --want-drop, --largerthan, --smallerthan, --accessedwithin
* Commands supporting --branch now apply file matching options --include,
--exclude, --want-get, --want-drop to filenames from the branch.
Previously, combining --branch with those would fail to match anything.
* add, import, findref: Support --time-limit.
This commit was sponsored by Jake Vosloo on Patreon.
2018-12-09 17:38:35 +00:00
|
|
|
_ -> MatchingKey k (AssociatedFile Nothing)
|
|
|
|
in whenM (matcher i) $
|
2018-10-01 18:12:06 +00:00
|
|
|
keyaction v
|
2020-07-24 16:05:28 +00:00
|
|
|
checkseeker k a = case checkContentPresent seeker of
|
|
|
|
Nothing -> a
|
|
|
|
Just v -> do
|
|
|
|
present <- inAnnex k
|
|
|
|
when (present == v) a
|
2016-07-20 19:22:55 +00:00
|
|
|
|
|
|
|
withKeyOptions'
|
|
|
|
:: Maybe KeyOptions
|
|
|
|
-> Bool
|
2018-10-01 18:12:06 +00:00
|
|
|
-> Annex ((Key, ActionItem) -> Annex ())
|
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 -> CommandSeek)
|
|
|
|
-> WorkTreeItems
|
2016-07-20 19:22:55 +00:00
|
|
|
-> CommandSeek
|
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
|
|
|
withKeyOptions' ko auto mkkeyaction fallbackaction worktreeitems = do
|
2013-07-03 19:26:59 +00:00
|
|
|
bare <- fromRepo Git.repoIsLocalBare
|
2014-01-26 18:59:47 +00:00
|
|
|
when (auto && bare) $
|
2016-11-16 01:29:54 +00:00
|
|
|
giveup "Cannot use --auto in a bare repository"
|
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
|
|
|
case (noworktreeitems, ko) of
|
2015-07-09 16:44:03 +00:00
|
|
|
(True, Nothing)
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
| bare -> noauto runallkeys
|
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
|
|
|
| otherwise -> fallbackaction worktreeitems
|
|
|
|
(False, Nothing) -> fallbackaction worktreeitems
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
(True, Just WantAllKeys) -> noauto runallkeys
|
|
|
|
(True, Just WantUnusedKeys) -> noauto $ runkeyaction unusedKeys'
|
2016-08-03 16:37:12 +00:00
|
|
|
(True, Just WantFailedTransfers) -> noauto runfailedtransfers
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
(True, Just (WantSpecificKey k)) -> noauto $ runkeyaction (return [k])
|
|
|
|
(True, Just WantIncompleteKeys) -> noauto $ runkeyaction incompletekeys
|
--branch, stage 1
Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and
whereis commands. This option makes git-annex operate on files that are
included in a specified branch (or other treeish).
The names of the files from the branch that are being operated on are not
displayed yet; only the keys. Displaying the filenames will need changes
to every affected command.
Also, note that --branch can be specified repeatedly. This is not really
documented, but seemed worth supporting, especially since we may later want
the ability to operate on all branches matching a refspec. However, when
operating on two branches that contain the same key, that key will be
operated on twice.
2016-07-20 16:05:22 +00:00
|
|
|
(True, Just (WantBranchKeys bs)) -> noauto $ runbranchkeys bs
|
2016-11-16 01:29:54 +00:00
|
|
|
(False, Just _) -> giveup "Can only specify one of file names, --all, --branch, --unused, --failed, --key, or --incomplete"
|
2013-07-03 17:02:42 +00:00
|
|
|
where
|
--branch, stage 1
Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and
whereis commands. This option makes git-annex operate on files that are
included in a specified branch (or other treeish).
The names of the files from the branch that are being operated on are not
displayed yet; only the keys. Displaying the filenames will need changes
to every affected command.
Also, note that --branch can be specified repeatedly. This is not really
documented, but seemed worth supporting, especially since we may later want
the ability to operate on all branches matching a refspec. However, when
operating on two branches that contain the same key, that key will be
operated on twice.
2016-07-20 16:05:22 +00:00
|
|
|
noauto a
|
2016-11-16 01:29:54 +00:00
|
|
|
| auto = giveup "Cannot use --auto with --all or --branch or --unused or --key or --incomplete"
|
--branch, stage 1
Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and
whereis commands. This option makes git-annex operate on files that are
included in a specified branch (or other treeish).
The names of the files from the branch that are being operated on are not
displayed yet; only the keys. Displaying the filenames will need changes
to every affected command.
Also, note that --branch can be specified repeatedly. This is not really
documented, but seemed worth supporting, especially since we may later want
the ability to operate on all branches matching a refspec. However, when
operating on two branches that contain the same key, that key will be
operated on twice.
2016-07-20 16:05:22 +00:00
|
|
|
| otherwise = a
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
|
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
|
|
|
noworktreeitems = case worktreeitems of
|
|
|
|
WorkTreeItems [] -> True
|
|
|
|
WorkTreeItems _ -> False
|
|
|
|
NoWorkTreeItems -> False
|
|
|
|
|
2015-06-02 18:20:38 +00:00
|
|
|
incompletekeys = staleKeysPrune gitAnnexTmpObjectDir True
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
|
|
|
|
-- List all location log files on the git-annex branch,
|
|
|
|
-- and use those to get keys. Pass through cat-file
|
|
|
|
-- to get the contents of the location logs, and pre-cache
|
|
|
|
-- those. This significantly speeds up typical operations
|
|
|
|
-- that need to look at the location log for each key.
|
|
|
|
runallkeys = do
|
|
|
|
keyaction <- mkkeyaction
|
|
|
|
config <- Annex.getGitConfig
|
|
|
|
g <- Annex.gitRepo
|
|
|
|
|
|
|
|
void Annex.Branch.update
|
|
|
|
(l, cleanup) <- inRepo $ LsTree.lsTree
|
|
|
|
LsTree.LsTreeRecursive
|
|
|
|
Annex.Branch.fullname
|
2020-07-14 16:44:35 +00:00
|
|
|
let getk f = fmap (,f) (locationLogFileKey config f)
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
let go reader = liftIO reader >>= \case
|
|
|
|
Nothing -> return ()
|
2020-07-14 16:44:35 +00:00
|
|
|
Just ((k, f), content) -> do
|
|
|
|
maybe noop (Annex.BranchState.setCache f) content
|
|
|
|
keyaction (k, mkActionItem k)
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
go reader
|
2020-07-14 16:44:35 +00:00
|
|
|
catObjectStreamLsTree l (getk . getTopFilePath . LsTree.file) g go
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
liftIO $ void cleanup
|
|
|
|
|
|
|
|
runkeyaction getks = do
|
--branch, stage 1
Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and
whereis commands. This option makes git-annex operate on files that are
included in a specified branch (or other treeish).
The names of the files from the branch that are being operated on are not
displayed yet; only the keys. Displaying the filenames will need changes
to every affected command.
Also, note that --branch can be specified repeatedly. This is not really
documented, but seemed worth supporting, especially since we may later want
the ability to operate on all branches matching a refspec. However, when
operating on two branches that contain the same key, that key will be
operated on twice.
2016-07-20 16:05:22 +00:00
|
|
|
keyaction <- mkkeyaction
|
2016-07-20 19:22:55 +00:00
|
|
|
ks <- getks
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
forM_ ks $ \k -> keyaction (k, mkActionItem k)
|
|
|
|
|
--branch, stage 1
Added --branch option to copy, drop, fsck, get, metadata, mirror, move, and
whereis commands. This option makes git-annex operate on files that are
included in a specified branch (or other treeish).
The names of the files from the branch that are being operated on are not
displayed yet; only the keys. Displaying the filenames will need changes
to every affected command.
Also, note that --branch can be specified repeatedly. This is not really
documented, but seemed worth supporting, especially since we may later want
the ability to operate on all branches matching a refspec. However, when
operating on two branches that contain the same key, that key will be
operated on twice.
2016-07-20 16:05:22 +00:00
|
|
|
runbranchkeys bs = do
|
|
|
|
keyaction <- mkkeyaction
|
|
|
|
forM_ bs $ \b -> do
|
2019-02-21 21:32:59 +00:00
|
|
|
(l, cleanup) <- inRepo $ LsTree.lsTree LsTree.LsTreeRecursive b
|
2019-06-06 16:53:24 +00:00
|
|
|
forM_ l $ \i -> catKey (LsTree.sha i) >>= \case
|
|
|
|
Nothing -> noop
|
|
|
|
Just k ->
|
|
|
|
let bfp = mkActionItem (BranchFilePath b (LsTree.file i), k)
|
|
|
|
in keyaction (k, bfp)
|
2016-07-20 17:44:33 +00:00
|
|
|
unlessM (liftIO cleanup) $
|
|
|
|
error ("git ls-tree " ++ Git.fromRef b ++ " failed")
|
sped up the --all option by 2x to 16x by using git cat-file --buffer
This assumes that no location log files will have a newline or carriage
return in their name. catObjectStream skips any such files due to
cat-file not supporting them.
Keys have been prevented from containing newlines since 2011,
commit 480495beb4a3422f006ee529df807a20cc944727. If some old repo
had a key with a newline in it, --all will just skip processing that key.
Other things, like .git/annex/unused files certianly assume no newlines in
keys too, and AFAICR, such keys never actually worked.
Carriage return is escaped by preSanitizeKeyName since 2013. WORM keys
generated before that point could perhaps contain a CR. (URL probably not,
http probably doesn't support an URL with a raw CR in it.) So, added
a warning in fsck about such keys. Although, fsck --all will naturally
skip them, so won't be able to warn about them. Not entirely
satisfactory, but I'll bet there are not really any such keys in
existence.
Thanks to Lukey for finding this optimisation.
2020-07-07 17:46:45 +00:00
|
|
|
|
2016-08-03 16:37:12 +00:00
|
|
|
runfailedtransfers = do
|
|
|
|
keyaction <- mkkeyaction
|
|
|
|
rs <- remoteList
|
|
|
|
ts <- concat <$> mapM (getFailedTransfers . Remote.uuid) rs
|
|
|
|
forM_ ts $ \(t, i) ->
|
2018-10-01 18:12:06 +00:00
|
|
|
keyaction (transferKey t, mkActionItem (t, i))
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2020-07-10 17:54:52 +00:00
|
|
|
seekFiltered :: (RawFilePath -> CommandSeek) -> Annex [RawFilePath] -> Annex ()
|
|
|
|
seekFiltered a fs = do
|
2011-10-30 03:48:46 +00:00
|
|
|
matcher <- Limit.getMatcher
|
2020-07-10 17:54:52 +00:00
|
|
|
sequence_ =<< (map (process matcher) <$> fs)
|
2012-11-11 04:51:07 +00:00
|
|
|
where
|
2019-11-26 19:27:22 +00:00
|
|
|
process matcher f =
|
2019-12-09 17:49:05 +00:00
|
|
|
whenM (matcher $ MatchingFile $ FileInfo f f) $ a f
|
2011-10-30 03:48:46 +00:00
|
|
|
|
2020-07-13 21:04:02 +00:00
|
|
|
-- This is significantly faster than using lookupKey after seekFiltered,
|
|
|
|
-- because of the way data is streamed through git cat-file.
|
|
|
|
--
|
|
|
|
-- It can also precache location logs using the same efficient streaming.
|
|
|
|
seekFilteredKeys :: AnnexedFileSeeker -> Annex [(RawFilePath, Git.Sha, FileMode)] -> Annex ()
|
|
|
|
seekFilteredKeys seeker listfs = do
|
2020-07-10 17:54:52 +00:00
|
|
|
g <- Annex.gitRepo
|
2020-07-10 19:11:14 +00:00
|
|
|
matcher <- Limit.getMatcher
|
2020-07-13 21:04:02 +00:00
|
|
|
config <- Annex.getGitConfig
|
2020-07-13 16:36:15 +00:00
|
|
|
-- Run here, not in the async, because it could throw an exception
|
|
|
|
-- The list should be built lazily.
|
|
|
|
l <- listfs
|
2020-07-13 18:09:08 +00:00
|
|
|
catObjectMetaDataStream g $ \mdfeeder mdcloser mdreader ->
|
2020-07-13 21:04:02 +00:00
|
|
|
catObjectStream g $ \ofeeder ocloser oreader -> do
|
2020-07-13 18:09:08 +00:00
|
|
|
processertid <- liftIO . async =<< forkState
|
2020-07-13 21:04:02 +00:00
|
|
|
(process matcher ofeeder mdfeeder mdcloser False l)
|
2020-07-13 18:09:08 +00:00
|
|
|
mdprocessertid <- liftIO . async =<< forkState
|
2020-07-13 21:04:02 +00:00
|
|
|
(mdprocess matcher mdreader ofeeder ocloser)
|
|
|
|
if usesLocationLog seeker
|
|
|
|
then catObjectStream g $ \lfeeder lcloser lreader -> do
|
|
|
|
precachertid <- liftIO . async =<< forkState
|
|
|
|
(precacher config oreader lfeeder lcloser)
|
|
|
|
precachefinisher lreader
|
|
|
|
join (liftIO (wait precachertid))
|
|
|
|
else finisher oreader
|
2020-07-13 18:09:08 +00:00
|
|
|
join (liftIO (wait mdprocessertid))
|
|
|
|
join (liftIO (wait processertid))
|
2020-07-10 17:54:52 +00:00
|
|
|
where
|
2020-07-13 21:04:02 +00:00
|
|
|
checkpresence k cont = case checkContentPresent seeker of
|
|
|
|
Just v -> do
|
|
|
|
present <- inAnnex k
|
|
|
|
when (present == v) cont
|
|
|
|
Nothing -> cont
|
|
|
|
|
|
|
|
finisher oreader = liftIO oreader >>= \case
|
2020-07-10 17:54:52 +00:00
|
|
|
Just (f, content) -> do
|
2020-07-13 21:04:02 +00:00
|
|
|
case parseLinkTargetOrPointerLazy =<< content of
|
|
|
|
Just k -> checkpresence k $
|
2020-07-22 18:23:28 +00:00
|
|
|
commandAction $
|
|
|
|
startAction seeker f k
|
2020-07-13 21:04:02 +00:00
|
|
|
Nothing -> noop
|
|
|
|
finisher oreader
|
|
|
|
Nothing -> return ()
|
|
|
|
|
|
|
|
precachefinisher lreader = liftIO lreader >>= \case
|
|
|
|
Just ((logf, f, k), logcontent) -> do
|
|
|
|
maybe noop (Annex.BranchState.setCache logf) logcontent
|
2020-07-22 18:23:28 +00:00
|
|
|
commandAction $ startAction seeker f k
|
2020-07-13 21:04:02 +00:00
|
|
|
precachefinisher lreader
|
2020-07-10 19:11:14 +00:00
|
|
|
Nothing -> return ()
|
|
|
|
|
2020-07-13 21:04:02 +00:00
|
|
|
precacher config oreader lfeeder lcloser = liftIO oreader >>= \case
|
|
|
|
Just (f, content) -> do
|
|
|
|
case parseLinkTargetOrPointerLazy =<< content of
|
|
|
|
Just k -> checkpresence k $
|
|
|
|
let logf = locationLogFile config k
|
|
|
|
ref = Git.Ref.branchFileRef Annex.Branch.fullname logf
|
|
|
|
in liftIO $ lfeeder ((logf, f, k), ref)
|
|
|
|
Nothing -> noop
|
|
|
|
precacher config oreader lfeeder lcloser
|
|
|
|
Nothing -> liftIO $ void lcloser
|
|
|
|
|
|
|
|
feedmatches matcher ofeeder f sha =
|
2020-07-10 19:11:14 +00:00
|
|
|
whenM (matcher $ MatchingFile $ FileInfo f f) $
|
2020-07-13 21:04:02 +00:00
|
|
|
liftIO $ ofeeder (f, sha)
|
2020-07-10 19:11:14 +00:00
|
|
|
|
2020-07-13 21:04:02 +00:00
|
|
|
process matcher ofeeder mdfeeder mdcloser seenpointer ((f, sha, mode):rest) =
|
2020-07-13 18:09:08 +00:00
|
|
|
case Git.toTreeItemType mode of
|
|
|
|
Just Git.TreeSymlink -> do
|
fix reversion in skipping deleted files
And add a test case for that.
This certianly loses some of the 2x performance improvement in file
seeking that seekFilteredKeys led to, because now it has to stat the
worktree files again. Without benchmarking, I expect there will still be
a sizable improvement, and also the git-annex branch precaching that
seekFilteredKeys can do will still be a win of its approach.
Also worth noting that lookupKey, when the file DNE, check if it's in an
adjusted branch with hidden files, and if so, finds the key for the
file anyway. That was intended to make git-annex sync --content be able
to process those files, but a side effect was that, when a file was
deleted but the deletion not yet staged, git-annex commands used to
still list it. That was actually a bug. This commit fixes that bug too.
(git-annex sync --content on such a branch does not use seekFilteredKeys
so was not affected by the reversion or by this behavior change)
This commit was sponsored by Jake Vosloo on Patreon.
2020-07-20 00:33:10 +00:00
|
|
|
whenM (exists f) $
|
|
|
|
-- Once a pointer file has been seen,
|
|
|
|
-- symlinks have to be sent via the
|
|
|
|
-- metadata processor too. That is slightly
|
|
|
|
-- slower, but preserves the requested
|
|
|
|
-- file order.
|
|
|
|
if seenpointer
|
|
|
|
then liftIO $ mdfeeder (f, sha)
|
|
|
|
else feedmatches matcher ofeeder f sha
|
2020-07-13 21:04:02 +00:00
|
|
|
process matcher ofeeder mdfeeder mdcloser seenpointer rest
|
2020-07-13 18:09:08 +00:00
|
|
|
Just Git.TreeSubmodule ->
|
2020-07-13 21:04:02 +00:00
|
|
|
process matcher ofeeder mdfeeder mdcloser seenpointer rest
|
2020-07-10 19:11:14 +00:00
|
|
|
-- Might be a pointer file, might be other
|
|
|
|
-- file in git, possibly large. Avoid catting
|
|
|
|
-- large files by first looking up the size.
|
2020-07-13 18:09:08 +00:00
|
|
|
Just _ -> do
|
fix reversion in skipping deleted files
And add a test case for that.
This certianly loses some of the 2x performance improvement in file
seeking that seekFilteredKeys led to, because now it has to stat the
worktree files again. Without benchmarking, I expect there will still be
a sizable improvement, and also the git-annex branch precaching that
seekFilteredKeys can do will still be a win of its approach.
Also worth noting that lookupKey, when the file DNE, check if it's in an
adjusted branch with hidden files, and if so, finds the key for the
file anyway. That was intended to make git-annex sync --content be able
to process those files, but a side effect was that, when a file was
deleted but the deletion not yet staged, git-annex commands used to
still list it. That was actually a bug. This commit fixes that bug too.
(git-annex sync --content on such a branch does not use seekFilteredKeys
so was not affected by the reversion or by this behavior change)
This commit was sponsored by Jake Vosloo on Patreon.
2020-07-20 00:33:10 +00:00
|
|
|
whenM (exists f) $
|
|
|
|
liftIO $ mdfeeder (f, sha)
|
2020-07-13 21:04:02 +00:00
|
|
|
process matcher ofeeder mdfeeder mdcloser True rest
|
2020-07-13 18:09:08 +00:00
|
|
|
Nothing ->
|
2020-07-13 21:04:02 +00:00
|
|
|
process matcher ofeeder mdfeeder mdcloser seenpointer rest
|
2020-07-13 18:09:08 +00:00
|
|
|
process _ _ _ mdcloser _ [] = liftIO $ void mdcloser
|
fix reversion in skipping deleted files
And add a test case for that.
This certianly loses some of the 2x performance improvement in file
seeking that seekFilteredKeys led to, because now it has to stat the
worktree files again. Without benchmarking, I expect there will still be
a sizable improvement, and also the git-annex branch precaching that
seekFilteredKeys can do will still be a win of its approach.
Also worth noting that lookupKey, when the file DNE, check if it's in an
adjusted branch with hidden files, and if so, finds the key for the
file anyway. That was intended to make git-annex sync --content be able
to process those files, but a side effect was that, when a file was
deleted but the deletion not yet staged, git-annex commands used to
still list it. That was actually a bug. This commit fixes that bug too.
(git-annex sync --content on such a branch does not use seekFilteredKeys
so was not affected by the reversion or by this behavior change)
This commit was sponsored by Jake Vosloo on Patreon.
2020-07-20 00:33:10 +00:00
|
|
|
|
|
|
|
-- Check if files exist, because a deleted file will still be
|
|
|
|
-- listed by ls-tree, but should not be processed.
|
|
|
|
exists p = isJust <$> liftIO (catchMaybeIO $ R.getSymbolicLinkStatus p)
|
2020-07-13 18:09:08 +00:00
|
|
|
|
2020-07-13 21:04:02 +00:00
|
|
|
mdprocess matcher mdreader ofeeder ocloser = liftIO mdreader >>= \case
|
2020-07-13 18:09:08 +00:00
|
|
|
Just (f, Just (sha, size, _type))
|
|
|
|
| size < maxPointerSz -> do
|
2020-07-13 21:04:02 +00:00
|
|
|
feedmatches matcher ofeeder f sha
|
|
|
|
mdprocess matcher mdreader ofeeder ocloser
|
|
|
|
Just _ -> mdprocess matcher mdreader ofeeder ocloser
|
|
|
|
Nothing -> liftIO $ void ocloser
|
2020-07-10 19:11:14 +00:00
|
|
|
|
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
|
|
|
seekHelper :: (a -> RawFilePath) -> WarnUnmatchWhen -> ([LsFiles.Options] -> [RawFilePath] -> Git.Repo -> IO ([a], IO Bool)) -> WorkTreeItems -> Annex [a]
|
|
|
|
seekHelper c ww a (WorkTreeItems l) = do
|
2020-05-28 19:55:17 +00:00
|
|
|
os <- seekOptions ww
|
|
|
|
inRepo $ \g ->
|
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
|
|
|
concat . concat <$> forM (segmentXargsOrdered l)
|
2020-07-10 17:54:52 +00:00
|
|
|
(runSegmentPaths c (\fs -> Git.Command.leaveZombie <$> a os fs g) . map toRawFilePath)
|
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
|
|
|
seekHelper _ _ _ NoWorkTreeItems = return []
|
2017-10-16 18:10:03 +00:00
|
|
|
|
2020-05-28 19:55:17 +00:00
|
|
|
data WarnUnmatchWhen = WarnUnmatchLsFiles | WarnUnmatchWorkTreeItems
|
|
|
|
|
|
|
|
seekOptions :: WarnUnmatchWhen -> Annex [LsFiles.Options]
|
|
|
|
seekOptions WarnUnmatchLsFiles =
|
|
|
|
ifM (annexSkipUnknown <$> Annex.getGitConfig)
|
|
|
|
( return []
|
|
|
|
, return [LsFiles.ErrorUnmatch]
|
|
|
|
)
|
|
|
|
seekOptions WarnUnmatchWorkTreeItems = return []
|
|
|
|
|
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
|
|
|
-- Items in the work tree, which may be files or directories.
|
|
|
|
data WorkTreeItems
|
|
|
|
= WorkTreeItems [FilePath]
|
|
|
|
-- ^ An empty list often means all files.
|
|
|
|
| NoWorkTreeItems
|
|
|
|
-- ^ Used when no work tree items should be operated on.
|
|
|
|
deriving (Show)
|
2013-02-06 16:40:59 +00:00
|
|
|
|
2018-10-19 21:51:25 +00:00
|
|
|
-- When in an adjusted branch that hides some files, it may not exist
|
|
|
|
-- in the current work tree, but in the original branch. This allows
|
|
|
|
-- seeking for such files.
|
|
|
|
newtype AllowHidden = AllowHidden Bool
|
|
|
|
|
2020-05-28 19:55:17 +00:00
|
|
|
-- git ls-files without --error-unmatch seeks work tree items matching
|
|
|
|
-- some criteria, and silently skips over anything that does not exist.
|
|
|
|
|
2020-05-11 19:03:35 +00:00
|
|
|
-- Also, when two directories are symlinked, referring to a file
|
2020-05-28 19:55:17 +00:00
|
|
|
-- inside the symlinked directory will be silently skipped by
|
|
|
|
-- git ls-files without --error-unmatch.
|
|
|
|
--
|
|
|
|
-- Sometimes a command needs to use git-lsfiles that way, perhaps repeatedly.
|
|
|
|
-- But users expect an error message when one of the files they provided
|
|
|
|
-- as a command-line parameter doesn't exist, so this checks that each
|
|
|
|
-- exists when run with WarnUnmatchWorkTreeItems.
|
|
|
|
--
|
|
|
|
-- Note that, unlike --error-unmatch, using this does not warn
|
|
|
|
-- about command-line parameters that exist, but are not checked into git.
|
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 :: WarnUnmatchWhen -> CmdParams -> Annex WorkTreeItems
|
2018-10-19 21:51:25 +00:00
|
|
|
workTreeItems = workTreeItems' (AllowHidden False)
|
|
|
|
|
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' :: AllowHidden -> WarnUnmatchWhen -> CmdParams -> Annex WorkTreeItems
|
|
|
|
workTreeItems' (AllowHidden allowhidden) ww ps = case ww of
|
|
|
|
WarnUnmatchWorkTreeItems -> runcheck
|
|
|
|
WarnUnmatchLsFiles ->
|
|
|
|
ifM (annexSkipUnknown <$> Annex.getGitConfig)
|
|
|
|
( runcheck
|
|
|
|
, return $ WorkTreeItems ps
|
|
|
|
)
|
2018-10-19 21:51:25 +00:00
|
|
|
where
|
2020-05-28 19:55:17 +00:00
|
|
|
runcheck = do
|
|
|
|
currbranch <- getCurrentBranch
|
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
|
|
|
ps' <- flip filterM ps $ \p -> do
|
2020-05-28 19:55:17 +00:00
|
|
|
relf <- liftIO $ relPathCwdToFile p
|
|
|
|
ifM (not <$> (exists p <||> hidden currbranch relf))
|
|
|
|
( prob (p ++ " not found")
|
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
|
|
|
, ifM (viasymlink (upFrom relf))
|
|
|
|
( prob (p ++ " is beyond a symbolic link")
|
|
|
|
, return True
|
|
|
|
)
|
2020-05-28 19:55:17 +00:00
|
|
|
)
|
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
|
|
|
if null ps' && not (null ps)
|
|
|
|
then return NoWorkTreeItems
|
|
|
|
else return (WorkTreeItems ps')
|
2020-05-28 19:55:17 +00:00
|
|
|
|
2018-10-19 21:51:25 +00:00
|
|
|
exists p = isJust <$> liftIO (catchMaybeIO $ getSymbolicLinkStatus p)
|
2020-05-11 19:03:35 +00:00
|
|
|
|
|
|
|
viasymlink Nothing = return False
|
|
|
|
viasymlink (Just p) =
|
|
|
|
ifM (liftIO $ isSymbolicLink <$> getSymbolicLinkStatus p)
|
|
|
|
( return True
|
|
|
|
, viasymlink (upFrom p)
|
|
|
|
)
|
|
|
|
|
|
|
|
hidden currbranch f
|
|
|
|
| allowhidden = isJust
|
|
|
|
<$> catObjectMetaDataHidden (toRawFilePath f) currbranch
|
2018-10-19 21:51:25 +00:00
|
|
|
| otherwise = return False
|
2017-06-01 15:40:47 +00:00
|
|
|
|
2020-05-11 19:03:35 +00:00
|
|
|
prob msg = do
|
|
|
|
toplevelWarning False msg
|
|
|
|
Annex.incError
|
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
|
|
|
return False
|
2020-05-11 19:03:35 +00:00
|
|
|
|
2019-11-25 20:18:19 +00:00
|
|
|
notSymlink :: RawFilePath -> IO Bool
|
2019-12-06 19:37:12 +00:00
|
|
|
notSymlink f = liftIO $ not . isSymbolicLink <$> R.getSymbolicLinkStatus f
|