2011-09-28 19:15:42 +00:00
|
|
|
{- git cat-file interface, with handle automatically stored in the Annex monad
|
|
|
|
-
|
2020-04-20 17:53:27 +00:00
|
|
|
- Copyright 2011-2020 Joey Hess <id@joeyh.name>
|
2011-09-28 19:15:42 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
2011-09-28 19:15:42 +00:00
|
|
|
-}
|
|
|
|
|
2020-04-20 17:53:27 +00:00
|
|
|
{-# LANGUAGE BangPatterns #-}
|
|
|
|
|
2011-10-04 04:40:47 +00:00
|
|
|
module Annex.CatFile (
|
2011-11-12 21:45:12 +00:00
|
|
|
catFile,
|
2014-03-03 18:57:16 +00:00
|
|
|
catFileDetails,
|
detect and recover from branch push/commit race
Dealing with a race without using locking is exceedingly difficult and tricky.
Fully tested, I hope.
There are three places left where the branch can be updated, that are not
covered by the race recovery code. Let's prove they're all immune to the
race:
1. tryFastForwardTo checks to see if a fast-forward can be done,
and then does git-update-ref on the branch to fast-forward it.
If a push comes in before the check, then either no fast-forward
will be done (ok), or the push set the branch to a ref that can
still be fast-forwarded (also ok)
If a push comes in after the check, the git-update-ref will
undo the ref change made by the push. It's as if the push did not come
in, and the next git-push will see this, and try to re-do it.
(acceptable)
2. When creating the branch for the very first time, an empty index
is created, and a commit of it made to the branch. The commit's ref
is recorded as the current state of the index. If a push came in
during that, it will be noticed the next time a commit is made to the
branch, since the branch will have changed. (ok)
3. Creating the branch from an existing remote branch involves making
the branch, and then getting its ref, and recording that the index
reflects that ref.
If a push creates the branch first, git-branch will fail (ok).
If the branch is created and a racing push is then able to change it
(highly unlikely!) we're still ok, because it first records the ref into
the index.lck, and then updating the index. The race can cause the
index.lck to have the old branch ref, while the index has the newly pushed
branch merged into it, but that only results in an unnecessary update of
the index file later on.
2011-12-11 22:39:53 +00:00
|
|
|
catObject,
|
2013-09-19 20:30:37 +00:00
|
|
|
catTree,
|
2016-02-25 19:34:46 +00:00
|
|
|
catCommit,
|
2012-06-10 23:58:34 +00:00
|
|
|
catObjectDetails,
|
2020-04-20 17:53:27 +00:00
|
|
|
withCatFileHandle,
|
2018-08-27 18:47:17 +00:00
|
|
|
catObjectMetaData,
|
2014-08-20 16:01:45 +00:00
|
|
|
catFileStop,
|
2012-12-12 23:20:38 +00:00
|
|
|
catKey,
|
2019-12-27 18:58:10 +00:00
|
|
|
catKey',
|
2018-10-19 21:51:25 +00:00
|
|
|
catSymLinkTarget,
|
2013-01-05 19:26:22 +00:00
|
|
|
catKeyFile,
|
2013-08-22 17:57:07 +00:00
|
|
|
catKeyFileHEAD,
|
2018-10-19 21:51:25 +00:00
|
|
|
catKeyFileHidden,
|
|
|
|
catObjectMetaDataHidden,
|
2011-09-28 19:15:42 +00:00
|
|
|
) where
|
|
|
|
|
2012-06-20 17:13:40 +00:00
|
|
|
import qualified Data.ByteString.Lazy as L
|
2013-05-15 22:46:38 +00:00
|
|
|
import qualified Data.Map as M
|
2013-09-19 20:30:37 +00:00
|
|
|
import System.PosixCompat.Types
|
2020-04-20 17:53:27 +00:00
|
|
|
import Control.Concurrent.STM
|
2011-11-12 21:45:12 +00:00
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
improve type signatures with a Ref newtype
In git, a Ref can be a Sha, or a Branch, or a Tag. I added type aliases for
those. Note that this does not prevent mixing up of eg, refs and branches
at the type level. Since git really doesn't care, except rare cases like
git update-ref, or git tag -d, that seems ok for now.
There's also a tree-ish, but let's just use Ref for it. A given Sha or Ref
may or may not be a tree-ish, depending on the object type, so there seems
no point in trying to represent it at the type level.
2011-11-16 06:23:34 +00:00
|
|
|
import qualified Git
|
2011-09-28 19:15:42 +00:00
|
|
|
import qualified Git.CatFile
|
|
|
|
import qualified Annex
|
2012-06-10 23:58:34 +00:00
|
|
|
import Git.Types
|
2013-05-12 22:18:48 +00:00
|
|
|
import Git.FilePath
|
2016-05-17 17:30:59 +00:00
|
|
|
import Git.Index
|
2013-11-07 17:55:36 +00:00
|
|
|
import qualified Git.Ref
|
2015-12-09 18:25:33 +00:00
|
|
|
import Annex.Link
|
2018-10-19 21:51:25 +00:00
|
|
|
import Annex.CurrentBranch
|
|
|
|
import Types.AdjustedBranch
|
2020-04-20 17:53:27 +00:00
|
|
|
import Types.CatFileHandles
|
|
|
|
import Utility.ResourcePool
|
2011-09-28 19:15:42 +00:00
|
|
|
|
2019-11-26 19:27:22 +00:00
|
|
|
catFile :: Git.Branch -> RawFilePath -> Annex L.ByteString
|
2020-04-20 17:53:27 +00:00
|
|
|
catFile branch file = withCatFileHandle $ \h ->
|
2011-11-12 21:45:12 +00:00
|
|
|
liftIO $ Git.CatFile.catFile h branch file
|
|
|
|
|
2019-11-26 19:27:22 +00:00
|
|
|
catFileDetails :: Git.Branch -> RawFilePath -> Annex (Maybe (L.ByteString, Sha, ObjectType))
|
2020-04-20 17:53:27 +00:00
|
|
|
catFileDetails branch file = withCatFileHandle $ \h ->
|
2014-03-03 18:57:16 +00:00
|
|
|
liftIO $ Git.CatFile.catFileDetails h branch file
|
|
|
|
|
detect and recover from branch push/commit race
Dealing with a race without using locking is exceedingly difficult and tricky.
Fully tested, I hope.
There are three places left where the branch can be updated, that are not
covered by the race recovery code. Let's prove they're all immune to the
race:
1. tryFastForwardTo checks to see if a fast-forward can be done,
and then does git-update-ref on the branch to fast-forward it.
If a push comes in before the check, then either no fast-forward
will be done (ok), or the push set the branch to a ref that can
still be fast-forwarded (also ok)
If a push comes in after the check, the git-update-ref will
undo the ref change made by the push. It's as if the push did not come
in, and the next git-push will see this, and try to re-do it.
(acceptable)
2. When creating the branch for the very first time, an empty index
is created, and a commit of it made to the branch. The commit's ref
is recorded as the current state of the index. If a push came in
during that, it will be noticed the next time a commit is made to the
branch, since the branch will have changed. (ok)
3. Creating the branch from an existing remote branch involves making
the branch, and then getting its ref, and recording that the index
reflects that ref.
If a push creates the branch first, git-branch will fail (ok).
If the branch is created and a racing push is then able to change it
(highly unlikely!) we're still ok, because it first records the ref into
the index.lck, and then updating the index. The race can cause the
index.lck to have the old branch ref, while the index has the newly pushed
branch merged into it, but that only results in an unnecessary update of
the index file later on.
2011-12-11 22:39:53 +00:00
|
|
|
catObject :: Git.Ref -> Annex L.ByteString
|
2020-04-20 17:53:27 +00:00
|
|
|
catObject ref = withCatFileHandle $ \h ->
|
detect and recover from branch push/commit race
Dealing with a race without using locking is exceedingly difficult and tricky.
Fully tested, I hope.
There are three places left where the branch can be updated, that are not
covered by the race recovery code. Let's prove they're all immune to the
race:
1. tryFastForwardTo checks to see if a fast-forward can be done,
and then does git-update-ref on the branch to fast-forward it.
If a push comes in before the check, then either no fast-forward
will be done (ok), or the push set the branch to a ref that can
still be fast-forwarded (also ok)
If a push comes in after the check, the git-update-ref will
undo the ref change made by the push. It's as if the push did not come
in, and the next git-push will see this, and try to re-do it.
(acceptable)
2. When creating the branch for the very first time, an empty index
is created, and a commit of it made to the branch. The commit's ref
is recorded as the current state of the index. If a push came in
during that, it will be noticed the next time a commit is made to the
branch, since the branch will have changed. (ok)
3. Creating the branch from an existing remote branch involves making
the branch, and then getting its ref, and recording that the index
reflects that ref.
If a push creates the branch first, git-branch will fail (ok).
If the branch is created and a racing push is then able to change it
(highly unlikely!) we're still ok, because it first records the ref into
the index.lck, and then updating the index. The race can cause the
index.lck to have the old branch ref, while the index has the newly pushed
branch merged into it, but that only results in an unnecessary update of
the index file later on.
2011-12-11 22:39:53 +00:00
|
|
|
liftIO $ Git.CatFile.catObject h ref
|
|
|
|
|
2019-12-27 18:58:10 +00:00
|
|
|
catObjectMetaData :: Git.Ref -> Annex (Maybe (Sha, Integer, ObjectType))
|
2020-04-20 17:53:27 +00:00
|
|
|
catObjectMetaData ref = withCatFileHandle $ \h ->
|
2016-10-05 19:21:36 +00:00
|
|
|
liftIO $ Git.CatFile.catObjectMetaData h ref
|
|
|
|
|
2013-09-19 20:30:37 +00:00
|
|
|
catTree :: Git.Ref -> Annex [(FilePath, FileMode)]
|
2020-04-20 17:53:27 +00:00
|
|
|
catTree ref = withCatFileHandle $ \h ->
|
2013-09-19 20:30:37 +00:00
|
|
|
liftIO $ Git.CatFile.catTree h ref
|
|
|
|
|
2016-02-25 19:34:46 +00:00
|
|
|
catCommit :: Git.Ref -> Annex (Maybe Commit)
|
2020-04-20 17:53:27 +00:00
|
|
|
catCommit ref = withCatFileHandle $ \h ->
|
2016-02-25 19:34:46 +00:00
|
|
|
liftIO $ Git.CatFile.catCommit h ref
|
|
|
|
|
2013-10-20 21:50:51 +00:00
|
|
|
catObjectDetails :: Git.Ref -> Annex (Maybe (L.ByteString, Sha, ObjectType))
|
2020-04-20 17:53:27 +00:00
|
|
|
catObjectDetails ref = withCatFileHandle $ \h ->
|
2012-06-10 23:58:34 +00:00
|
|
|
liftIO $ Git.CatFile.catObjectDetails h ref
|
|
|
|
|
2013-05-15 22:46:38 +00:00
|
|
|
{- There can be multiple index files, and a different cat-file is needed
|
2020-04-20 17:53:27 +00:00
|
|
|
- for each. That is selected by setting GIT_INDEX_FILE in the gitEnv
|
|
|
|
- before running this. -}
|
|
|
|
withCatFileHandle :: (Git.CatFile.CatFileHandle -> Annex a) -> Annex a
|
|
|
|
withCatFileHandle a = do
|
|
|
|
cfh <- Annex.getState Annex.catfilehandles
|
2016-05-17 17:30:59 +00:00
|
|
|
indexfile <- fromMaybe "" . maybe Nothing (lookup indexEnv)
|
2013-05-15 22:46:38 +00:00
|
|
|
<$> fromRepo gitEnv
|
2020-04-20 17:53:27 +00:00
|
|
|
p <- case cfh of
|
|
|
|
CatFileHandlesNonConcurrent m -> case M.lookup indexfile m of
|
|
|
|
Just p -> return p
|
|
|
|
Nothing -> do
|
|
|
|
p <- mkResourcePoolNonConcurrent startcatfile
|
|
|
|
let !m' = M.insert indexfile p m
|
|
|
|
Annex.changeState $ \s -> s { Annex.catfilehandles = CatFileHandlesNonConcurrent m' }
|
|
|
|
return p
|
|
|
|
CatFileHandlesPool tm -> do
|
|
|
|
m <- liftIO $ atomically $ takeTMVar tm
|
|
|
|
case M.lookup indexfile m of
|
|
|
|
Just p -> do
|
|
|
|
liftIO $ atomically $ putTMVar tm m
|
|
|
|
return p
|
|
|
|
Nothing -> do
|
|
|
|
p <- mkResourcePool maxCatFiles
|
|
|
|
let !m' = M.insert indexfile p m
|
|
|
|
liftIO $ atomically $ putTMVar tm m'
|
|
|
|
return p
|
|
|
|
withResourcePool p startcatfile a
|
|
|
|
where
|
|
|
|
startcatfile = inRepo Git.CatFile.catFileStart
|
|
|
|
|
|
|
|
{- A lot of git cat-file processes are unlikely to improve concurrency,
|
|
|
|
- because a query to them takes only a little bit of CPU, and tends to be
|
|
|
|
- bottlenecked on disk. Also, they each open a number of files, so
|
|
|
|
- using too many might run out of file handles. So, only start a maximum
|
|
|
|
- of 2.
|
|
|
|
-
|
|
|
|
- Note that each different index file gets its own pool of cat-files;
|
|
|
|
- this is the size of each pool. In all, 4 times this many cat-files
|
|
|
|
- may end up running.
|
|
|
|
-}
|
|
|
|
maxCatFiles :: Int
|
|
|
|
maxCatFiles = 2
|
2012-12-12 23:20:38 +00:00
|
|
|
|
2014-08-20 16:01:45 +00:00
|
|
|
{- Stops all running cat-files. Should only be run when it's known that
|
|
|
|
- nothing is using the handles, eg at shutdown. -}
|
|
|
|
catFileStop :: Annex ()
|
|
|
|
catFileStop = do
|
2020-04-20 17:53:27 +00:00
|
|
|
cfh <- Annex.getState Annex.catfilehandles
|
|
|
|
m <- case cfh of
|
|
|
|
CatFileHandlesNonConcurrent m -> do
|
|
|
|
Annex.changeState $ \s -> s { Annex.catfilehandles = CatFileHandlesNonConcurrent M.empty }
|
|
|
|
return m
|
|
|
|
CatFileHandlesPool tm ->
|
|
|
|
liftIO $ atomically $ swapTMVar tm M.empty
|
|
|
|
liftIO $ forM_ (M.elems m) $ \p ->
|
|
|
|
freeResourcePool p Git.CatFile.catFileStop
|
2014-08-20 16:01:45 +00:00
|
|
|
|
2015-12-07 19:22:01 +00:00
|
|
|
{- From ref to a symlink or a pointer file, get the key. -}
|
|
|
|
catKey :: Ref -> Annex (Maybe Key)
|
2021-03-16 18:52:23 +00:00
|
|
|
catKey ref = catObjectMetaData ref >>= \case
|
|
|
|
Just (_, sz, _) -> catKey' ref sz
|
|
|
|
Nothing -> return Nothing
|
2019-12-27 18:58:10 +00:00
|
|
|
|
2021-03-16 18:52:23 +00:00
|
|
|
catKey' :: Ref -> FileSize -> Annex (Maybe Key)
|
|
|
|
catKey' ref sz
|
2019-12-27 18:58:10 +00:00
|
|
|
-- Avoid catting large files, that cannot be symlinks or
|
|
|
|
-- pointer files, which would require buffering their
|
|
|
|
-- content in memory, as well as a lot of IO.
|
|
|
|
| sz <= maxPointerSz =
|
|
|
|
parseLinkTargetOrPointer . L.toStrict <$> catObject ref
|
|
|
|
catKey' _ _ = return Nothing
|
2014-07-08 17:54:42 +00:00
|
|
|
|
|
|
|
{- Gets a symlink target. -}
|
2019-11-26 19:27:22 +00:00
|
|
|
catSymLinkTarget :: Sha -> Annex RawFilePath
|
|
|
|
catSymLinkTarget sha = fromInternalGitPath . L.toStrict <$> get
|
2013-09-19 20:30:37 +00:00
|
|
|
where
|
2015-12-07 19:22:01 +00:00
|
|
|
-- Avoid buffering the whole file content, which might be large.
|
2015-12-26 17:47:36 +00:00
|
|
|
-- 8192 is enough if it really is a symlink.
|
2015-12-07 19:22:01 +00:00
|
|
|
get = L.take 8192 <$> catObject sha
|
2013-01-05 19:26:22 +00:00
|
|
|
|
2013-05-25 04:37:41 +00:00
|
|
|
{- From a file in the repository back to the key.
|
|
|
|
-
|
|
|
|
- Ideally, this should reflect the key that's staged in the index,
|
|
|
|
- not the key that's committed to HEAD. Unfortunately, git cat-file
|
|
|
|
- does not refresh the index file after it's started up, so things
|
|
|
|
- newly staged in the index won't show up. It does, however, notice
|
|
|
|
- when branches change.
|
|
|
|
-
|
|
|
|
- For command-line git-annex use, that doesn't matter. It's perfectly
|
|
|
|
- reasonable for things staged in the index after the currently running
|
2013-09-19 20:30:37 +00:00
|
|
|
- git-annex process to not be noticed by it. However, we do want to see
|
2013-12-15 18:02:23 +00:00
|
|
|
- what's in the index, since it may have uncommitted changes not in HEAD
|
2013-05-25 04:37:41 +00:00
|
|
|
-
|
|
|
|
- For the assistant, this is much more of a problem, since it commits
|
|
|
|
- files and then needs to be able to immediately look up their keys.
|
|
|
|
- OTOH, the assistant doesn't keep changes staged in the index for very
|
|
|
|
- long at all before committing them -- and it won't look at the keys
|
|
|
|
- of files until after committing them.
|
|
|
|
-
|
|
|
|
- So, this gets info from the index, unless running as a daemon.
|
2013-01-05 19:26:22 +00:00
|
|
|
-}
|
2019-11-26 19:27:22 +00:00
|
|
|
catKeyFile :: RawFilePath -> Annex (Maybe Key)
|
2013-05-25 04:37:41 +00:00
|
|
|
catKeyFile f = ifM (Annex.getState Annex.daemon)
|
2013-08-22 17:57:07 +00:00
|
|
|
( catKeyFileHEAD f
|
2015-12-07 19:22:01 +00:00
|
|
|
, catKey $ Git.Ref.fileRef f
|
2013-05-25 04:37:41 +00:00
|
|
|
)
|
2013-08-22 17:57:07 +00:00
|
|
|
|
2019-11-26 19:27:22 +00:00
|
|
|
catKeyFileHEAD :: RawFilePath -> Annex (Maybe Key)
|
2015-12-07 19:22:01 +00:00
|
|
|
catKeyFileHEAD f = catKey $ Git.Ref.fileFromRef Git.Ref.headRef f
|
2018-10-19 21:51:25 +00:00
|
|
|
|
|
|
|
{- Look in the original branch from whence an adjusted branch is based
|
|
|
|
- to find the file. But only when the adjustment hides some files. -}
|
2019-11-26 19:27:22 +00:00
|
|
|
catKeyFileHidden :: RawFilePath -> CurrBranch -> Annex (Maybe Key)
|
2018-10-19 21:51:25 +00:00
|
|
|
catKeyFileHidden = hiddenCat catKey
|
|
|
|
|
2019-12-27 18:58:10 +00:00
|
|
|
catObjectMetaDataHidden :: RawFilePath -> CurrBranch -> Annex (Maybe (Sha, Integer, ObjectType))
|
2018-10-19 21:51:25 +00:00
|
|
|
catObjectMetaDataHidden = hiddenCat catObjectMetaData
|
|
|
|
|
2019-11-26 19:27:22 +00:00
|
|
|
hiddenCat :: (Ref -> Annex (Maybe a)) -> RawFilePath -> CurrBranch -> Annex (Maybe a)
|
2018-10-19 21:51:25 +00:00
|
|
|
hiddenCat a f (Just origbranch, Just adj)
|
|
|
|
| adjustmentHidesFiles adj = a (Git.Ref.fileFromRef origbranch f)
|
|
|
|
hiddenCat _ _ _ = return Nothing
|