2011-06-21 20:08:09 +00:00
|
|
|
{- management of the git-annex branch
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
-
|
|
|
|
- Copyright 2011 Joey Hess <joey@kitenet.net>
|
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
2011-10-04 04:40:47 +00:00
|
|
|
module Annex.Branch (
|
2011-06-22 19:58:30 +00:00
|
|
|
create,
|
2011-06-21 20:08:09 +00:00
|
|
|
update,
|
2011-10-27 18:04:18 +00:00
|
|
|
disableUpdate,
|
2011-06-21 23:11:55 +00:00
|
|
|
get,
|
|
|
|
change,
|
2011-06-22 21:47:06 +00:00
|
|
|
commit,
|
2011-06-24 15:59:34 +00:00
|
|
|
files,
|
|
|
|
refExists,
|
|
|
|
hasOrigin,
|
2011-08-17 18:14:43 +00:00
|
|
|
hasSomeBranch,
|
2011-06-24 15:59:34 +00:00
|
|
|
name
|
2011-06-21 20:08:09 +00:00
|
|
|
) where
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
|
2011-06-30 04:35:51 +00:00
|
|
|
import System.IO.Binary
|
2011-07-05 17:26:59 +00:00
|
|
|
import System.Exit
|
2011-09-30 03:43:42 +00:00
|
|
|
import qualified Data.ByteString.Lazy.Char8 as L
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
|
2011-10-05 20:02:51 +00:00
|
|
|
import Common.Annex
|
2011-10-04 04:34:04 +00:00
|
|
|
import Annex.Exception
|
2011-06-22 19:58:30 +00:00
|
|
|
import Types.BranchState
|
2011-06-30 17:16:57 +00:00
|
|
|
import qualified Git
|
2011-06-30 17:32:47 +00:00
|
|
|
import qualified Git.UnionMerge
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
import qualified Annex
|
2011-10-04 04:40:47 +00:00
|
|
|
import Annex.CatFile
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
|
2011-06-28 18:14:49 +00:00
|
|
|
type GitRef = String
|
|
|
|
|
2011-06-21 21:39:45 +00:00
|
|
|
{- Name of the branch that is used to store git-annex's information. -}
|
2011-06-28 18:14:49 +00:00
|
|
|
name :: GitRef
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
name = "git-annex"
|
|
|
|
|
2011-06-21 21:39:45 +00:00
|
|
|
{- Fully qualified name of the branch. -}
|
2011-06-28 18:14:49 +00:00
|
|
|
fullname :: GitRef
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
fullname = "refs/heads/" ++ name
|
|
|
|
|
2011-06-24 15:59:34 +00:00
|
|
|
{- Branch's name in origin. -}
|
2011-06-28 18:14:49 +00:00
|
|
|
originname :: GitRef
|
2011-06-24 15:59:34 +00:00
|
|
|
originname = "origin/" ++ name
|
|
|
|
|
2011-06-21 21:39:45 +00:00
|
|
|
{- A separate index file for the branch. -}
|
|
|
|
index :: Git.Repo -> FilePath
|
2011-06-23 16:11:09 +00:00
|
|
|
index g = gitAnnexDir g </> "index"
|
2011-06-21 21:39:45 +00:00
|
|
|
|
|
|
|
{- Populates the branch's index file with the current branch contents.
|
|
|
|
-
|
|
|
|
- Usually, this is only done when the index doesn't yet exist, and
|
2011-06-23 15:37:26 +00:00
|
|
|
- the index is used to build up changes to be commited to the branch,
|
|
|
|
- and merge in changes from other branches.
|
2011-06-21 21:39:45 +00:00
|
|
|
-}
|
2011-06-22 19:58:30 +00:00
|
|
|
genIndex :: Git.Repo -> IO ()
|
2011-11-08 19:34:10 +00:00
|
|
|
genIndex g = Git.UnionMerge.ls_tree fullname g >>= Git.UnionMerge.update_index g
|
2011-06-21 21:39:45 +00:00
|
|
|
|
|
|
|
{- Runs an action using the branch's index file. -}
|
|
|
|
withIndex :: Annex a -> Annex a
|
2011-06-23 02:56:27 +00:00
|
|
|
withIndex = withIndex' False
|
|
|
|
withIndex' :: Bool -> Annex a -> Annex a
|
|
|
|
withIndex' bootstrapping a = do
|
2011-11-08 19:34:10 +00:00
|
|
|
f <- fromRepo $ index
|
2011-10-04 04:34:04 +00:00
|
|
|
bracketIO (Git.useIndex f) id $ do
|
2011-10-04 04:19:42 +00:00
|
|
|
unlessM (liftIO $ doesFileExist f) $ do
|
|
|
|
unless bootstrapping create
|
|
|
|
liftIO $ createDirectoryIfMissing True $ takeDirectory f
|
2011-11-08 19:34:10 +00:00
|
|
|
unless bootstrapping $ inRepo genIndex
|
2011-10-04 04:19:42 +00:00
|
|
|
a
|
2011-06-21 21:39:45 +00:00
|
|
|
|
2011-06-22 19:58:30 +00:00
|
|
|
withIndexUpdate :: Annex a -> Annex a
|
|
|
|
withIndexUpdate a = update >> withIndex a
|
|
|
|
|
|
|
|
getState :: Annex BranchState
|
|
|
|
getState = Annex.getState Annex.branchstate
|
|
|
|
|
|
|
|
setState :: BranchState -> Annex ()
|
|
|
|
setState state = Annex.changeState $ \s -> s { Annex.branchstate = state }
|
|
|
|
|
2011-06-22 18:18:49 +00:00
|
|
|
setCache :: FilePath -> String -> Annex ()
|
2011-06-22 19:58:30 +00:00
|
|
|
setCache file content = do
|
|
|
|
state <- getState
|
|
|
|
setState state { cachedFile = Just file, cachedContent = content }
|
|
|
|
|
2011-06-22 18:18:49 +00:00
|
|
|
invalidateCache :: Annex ()
|
2011-06-22 19:58:30 +00:00
|
|
|
invalidateCache = do
|
|
|
|
state <- getState
|
|
|
|
setState state { cachedFile = Nothing, cachedContent = "" }
|
|
|
|
|
|
|
|
getCache :: FilePath -> Annex (Maybe String)
|
2011-10-04 04:34:04 +00:00
|
|
|
getCache file = getState >>= go
|
2011-06-22 19:58:30 +00:00
|
|
|
where
|
2011-10-04 04:34:04 +00:00
|
|
|
go state
|
2011-06-22 19:58:30 +00:00
|
|
|
| cachedFile state == Just file =
|
|
|
|
return $ Just $ cachedContent state
|
|
|
|
| otherwise = return Nothing
|
|
|
|
|
|
|
|
{- Creates the branch, if it does not already exist. -}
|
|
|
|
create :: Annex ()
|
2011-08-17 18:14:43 +00:00
|
|
|
create = unlessM hasBranch $ do
|
2011-06-28 18:14:49 +00:00
|
|
|
e <- hasOrigin
|
|
|
|
if e
|
2011-11-08 19:34:10 +00:00
|
|
|
then inRepo $ Git.run "branch" [Param name, Param originname]
|
2011-06-28 18:14:49 +00:00
|
|
|
else withIndex' True $
|
2011-11-08 19:34:10 +00:00
|
|
|
inRepo $ Git.commit "branch created" fullname []
|
2011-06-22 18:18:49 +00:00
|
|
|
|
2011-06-23 15:37:26 +00:00
|
|
|
{- Stages the journal, and commits staged changes to the branch. -}
|
2011-06-22 23:48:04 +00:00
|
|
|
commit :: String -> Annex ()
|
2011-10-09 20:19:09 +00:00
|
|
|
commit message = whenM journalDirty $ lockJournal $ do
|
|
|
|
stageJournalFiles
|
2011-11-08 19:34:10 +00:00
|
|
|
withIndex $ inRepo $ Git.commit message fullname [fullname]
|
2011-06-22 23:48:04 +00:00
|
|
|
|
merge: Use fast-forward merges when possible.
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
2011-11-06 19:18:45 +00:00
|
|
|
{- Ensures that the branch is up-to-date; should be called before data is
|
|
|
|
- read from it. Runs only once per git-annex run.
|
2011-10-09 20:19:09 +00:00
|
|
|
-
|
merge: Use fast-forward merges when possible.
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
2011-11-06 19:18:45 +00:00
|
|
|
- Before refs are merged into the index, it's important to first stage the
|
|
|
|
- journal into the index. Otherwise, any changes in the journal would
|
|
|
|
- later get staged, and might overwrite changes made during the merge.
|
2011-10-09 20:19:09 +00:00
|
|
|
-
|
merge: Use fast-forward merges when possible.
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
2011-11-06 19:18:45 +00:00
|
|
|
- It would be cleaner to handle the merge by updating the journal, not the
|
|
|
|
- index, with changes from the branches.
|
|
|
|
-
|
|
|
|
- The index is always updated using a union merge, as that's the most
|
|
|
|
- efficient way to update it. However, if the branch can be
|
|
|
|
- fast-forwarded, that is then done, rather than adding an unnecessary
|
|
|
|
- commit to it.
|
2011-10-09 20:19:09 +00:00
|
|
|
-}
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
update :: Annex ()
|
2011-10-07 17:59:34 +00:00
|
|
|
update = onceonly $ do
|
|
|
|
-- check what needs updating before taking the lock
|
2011-10-09 20:19:09 +00:00
|
|
|
dirty <- journalDirty
|
merge: Use fast-forward merges when possible.
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
2011-11-06 19:18:45 +00:00
|
|
|
c <- filterM (changedBranch name . snd) =<< siblingBranches
|
2011-10-07 17:59:34 +00:00
|
|
|
let (refs, branches) = unzip c
|
2011-10-09 20:19:09 +00:00
|
|
|
unless (not dirty && null refs) $ withIndex $ lockJournal $ do
|
2011-10-27 18:04:18 +00:00
|
|
|
when dirty stageJournalFiles
|
2011-10-07 17:59:34 +00:00
|
|
|
unless (null branches) $ do
|
|
|
|
showSideAction $ "merging " ++
|
|
|
|
(unwords $ map Git.refDescribe branches) ++
|
|
|
|
" into " ++ name
|
|
|
|
{- Note: This merges the branches into the index.
|
|
|
|
- Any unstaged changes in the git-annex branch
|
|
|
|
- (if it's checked out) will be removed. So,
|
|
|
|
- documentation advises users not to directly
|
|
|
|
- modify the branch.
|
2011-10-03 21:27:48 +00:00
|
|
|
-}
|
2011-11-08 19:34:10 +00:00
|
|
|
inRepo $ \g -> Git.UnionMerge.merge_index g branches
|
merge: Use fast-forward merges when possible.
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
2011-11-06 19:18:45 +00:00
|
|
|
ff <- if dirty then return False else tryFastForwardTo refs
|
2011-11-08 19:34:10 +00:00
|
|
|
unless ff $ inRepo $
|
|
|
|
Git.commit "update" fullname (nub $ fullname:refs)
|
2011-10-07 17:59:34 +00:00
|
|
|
invalidateCache
|
2011-10-03 21:27:48 +00:00
|
|
|
where
|
2011-10-07 17:59:34 +00:00
|
|
|
onceonly a = unlessM (branchUpdated <$> getState) $ do
|
|
|
|
r <- a
|
2011-10-27 18:04:18 +00:00
|
|
|
disableUpdate
|
2011-10-07 17:59:34 +00:00
|
|
|
return r
|
2011-10-27 18:04:18 +00:00
|
|
|
|
merge: Use fast-forward merges when possible.
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
2011-11-06 19:18:45 +00:00
|
|
|
{- Checks if the second branch has any commits not present on the first
|
|
|
|
- branch. -}
|
|
|
|
changedBranch :: String -> String -> Annex Bool
|
2011-11-08 19:34:10 +00:00
|
|
|
changedBranch origbranch newbranch = not . L.null <$> diffs
|
|
|
|
where
|
|
|
|
diffs = inRepo $ Git.pipeRead
|
|
|
|
[ Param "log"
|
|
|
|
, Param (origbranch ++ ".." ++ newbranch)
|
|
|
|
, Params "--oneline -n1"
|
|
|
|
]
|
merge: Use fast-forward merges when possible.
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
2011-11-06 19:18:45 +00:00
|
|
|
|
|
|
|
{- Given a set of refs that are all known to have commits not
|
|
|
|
- on the git-annex branch, tries to update the branch by a
|
|
|
|
- fast-forward.
|
|
|
|
-
|
|
|
|
- In order for that to be possible, one of the refs must contain
|
|
|
|
- every commit present in all the other refs, as well as in the
|
|
|
|
- git-annex branch.
|
|
|
|
-}
|
|
|
|
tryFastForwardTo :: [String] -> Annex Bool
|
|
|
|
tryFastForwardTo [] = return True
|
|
|
|
tryFastForwardTo (first:rest) = do
|
|
|
|
-- First, check that the git-annex branch does not contain any
|
|
|
|
-- new commits that are in the first other branch. If it does,
|
|
|
|
-- cannot fast-forward.
|
|
|
|
diverged <- changedBranch first fullname
|
|
|
|
if diverged
|
|
|
|
then no_ff
|
|
|
|
else maybe no_ff do_ff =<< findbest first rest
|
|
|
|
where
|
|
|
|
no_ff = return False
|
|
|
|
do_ff branch = do
|
2011-11-08 19:34:10 +00:00
|
|
|
inRepo $ Git.run "update-ref" [Param fullname, Param branch]
|
merge: Use fast-forward merges when possible.
Thanks Valentin Haenel for a test case showing how non-fast-forward merges
could result in an ongoing pull/merge/push cycle.
While the git-annex branch is fast-forwarded, git-annex's index file is still
updated using the union merge strategy as before. There's no other way to
update the index that would be any faster.
It is possible that a union merge and a fast-forward result in different file
contents: Files should have the same lines, but a union merge may change
their order. If this happens, the next commit made to the git-annex branch
will have some unnecessary changes to line orders, but the consistency
of data should be preserved.
Note that when the journal contains changes, a fast-forward is never attempted,
which is fine, because committing those changes would be vanishingly unlikely
to leave the git-annex branch at a commit that already exists in one of
the remotes.
The real difficulty is handling the case where multiple remotes have all
changed. git-annex does find the best (ie, newest) one and fast forwards
to it. If the remotes are diverged, no fast-forward is done at all. It would
be possible to pick one, fast forward to it, and make a merge commit to
the rest, I see no benefit to adding that complexity.
Determining the best of N changed remotes requires N*2+1 calls to git-log, but
these are fast git-log calls, and N is typically small. Also, typically
some or all of the remote refs will be the same, and git-log is not called to
compare those. In the real world I expect this will almost always add only
1 git-log call to the merge process. (Which already makes N anyway.)
2011-11-06 19:18:45 +00:00
|
|
|
return True
|
|
|
|
findbest c [] = return $ Just c
|
|
|
|
findbest c (r:rs)
|
|
|
|
| c == r = findbest c rs
|
|
|
|
| otherwise = do
|
|
|
|
better <- changedBranch c r
|
|
|
|
worse <- changedBranch r c
|
|
|
|
case (better, worse) of
|
|
|
|
(True, True) -> return Nothing -- divergent fail
|
|
|
|
(True, False) -> findbest r rs -- better
|
|
|
|
(False, True) -> findbest c rs -- worse
|
|
|
|
(False, False) -> findbest c rs -- same
|
|
|
|
|
2011-10-27 22:01:46 +00:00
|
|
|
{- Avoids updating the branch. A useful optimisation when the branch
|
2011-10-27 18:04:18 +00:00
|
|
|
- is known to have not changed, or git-annex won't be relying on info
|
|
|
|
- from it. -}
|
|
|
|
disableUpdate :: Annex ()
|
|
|
|
disableUpdate = Annex.changeState setupdated
|
|
|
|
where
|
2011-10-07 17:59:34 +00:00
|
|
|
setupdated s = s { Annex.branchstate = new }
|
|
|
|
where
|
|
|
|
new = old { branchUpdated = True }
|
|
|
|
old = Annex.branchstate s
|
code to update a git-annex branch
There is no suitable git hook to run code when pulling changes that
might need to be merged into the git-annex branch. The post-merge hook
is only run when changes are merged into HEAD, and it's possible,
and indeed likely that many pulls will only have changes in git-annex,
but not in HEAD, and not trigger it.
So, git-annex will have to take care to update the branch before reading
from it, to make sure it has merged in current info from remotes. Happily,
this can be done quite inexpensively, just a git-show-ref to list
branches, and a minimalized git-log to see if there are unmerged changes
on the branches. To further speed up, it will be done only once per
git-annex run, max.
2011-06-21 18:29:09 +00:00
|
|
|
|
2011-06-24 15:59:34 +00:00
|
|
|
{- Checks if a git ref exists. -}
|
2011-06-28 18:14:49 +00:00
|
|
|
refExists :: GitRef -> Annex Bool
|
2011-11-08 19:34:10 +00:00
|
|
|
refExists ref = inRepo $ Git.runBool "show-ref"
|
|
|
|
[Param "--verify", Param "-q", Param ref]
|
2011-06-24 15:59:34 +00:00
|
|
|
|
2011-08-17 18:14:43 +00:00
|
|
|
{- Does the main git-annex branch exist? -}
|
|
|
|
hasBranch :: Annex Bool
|
|
|
|
hasBranch = refExists fullname
|
|
|
|
|
|
|
|
{- Does origin/git-annex exist? -}
|
|
|
|
hasOrigin :: Annex Bool
|
|
|
|
hasOrigin = refExists originname
|
|
|
|
|
|
|
|
{- Does the git-annex branch or a foo/git-annex branch exist? -}
|
|
|
|
hasSomeBranch :: Annex Bool
|
2011-08-25 04:28:55 +00:00
|
|
|
hasSomeBranch = not . null <$> siblingBranches
|
2011-08-17 18:14:43 +00:00
|
|
|
|
2011-11-06 19:33:15 +00:00
|
|
|
{- List of git-annex (refs, branches), including the main one and any
|
|
|
|
- from remotes. Duplicate refs are filtered out. -}
|
2011-10-07 17:37:01 +00:00
|
|
|
siblingBranches :: Annex [(String, String)]
|
2011-08-17 18:14:43 +00:00
|
|
|
siblingBranches = do
|
2011-11-08 19:34:10 +00:00
|
|
|
r <- inRepo $ Git.pipeRead [Param "show-ref", Param name]
|
2011-11-06 19:33:15 +00:00
|
|
|
return $ nubBy uref $ map (pair . words . L.unpack) (L.lines r)
|
2011-10-07 17:37:01 +00:00
|
|
|
where
|
|
|
|
pair l = (head l, last l)
|
2011-11-06 19:33:15 +00:00
|
|
|
uref (a, _) (b, _) = a == b
|
2011-08-17 18:14:43 +00:00
|
|
|
|
2011-10-03 19:41:25 +00:00
|
|
|
{- Applies a function to modifiy the content of a file. -}
|
|
|
|
change :: FilePath -> (String -> String) -> Annex ()
|
2011-10-03 20:32:36 +00:00
|
|
|
change file a = lockJournal $ get file >>= return . a >>= set file
|
2011-10-03 19:41:25 +00:00
|
|
|
|
|
|
|
{- Records new content of a file into the journal. -}
|
|
|
|
set :: FilePath -> String -> Annex ()
|
|
|
|
set file content = do
|
2011-06-23 15:37:26 +00:00
|
|
|
setJournalFile file content
|
|
|
|
setCache file content
|
|
|
|
|
|
|
|
{- Gets the content of a file on the branch, or content from the journal, or
|
|
|
|
- staged in the index.
|
|
|
|
-
|
|
|
|
- Returns an empty string if the file doesn't exist yet. -}
|
2011-06-21 21:39:45 +00:00
|
|
|
get :: FilePath -> Annex String
|
2011-10-10 21:37:44 +00:00
|
|
|
get file = fromcache =<< getCache file
|
|
|
|
where
|
|
|
|
fromcache (Just content) = return content
|
|
|
|
fromcache Nothing = fromjournal =<< getJournalFile file
|
|
|
|
fromjournal (Just content) = cache content
|
|
|
|
fromjournal Nothing = withIndexUpdate $
|
|
|
|
cache =<< catFile fullname file
|
|
|
|
cache content = do
|
|
|
|
setCache file content
|
|
|
|
return content
|
2011-06-30 01:23:40 +00:00
|
|
|
|
2011-06-23 15:37:26 +00:00
|
|
|
{- Lists all files on the branch. There may be duplicates in the list. -}
|
2011-06-23 03:24:14 +00:00
|
|
|
files :: Annex [FilePath]
|
|
|
|
files = withIndexUpdate $ do
|
2011-11-08 19:34:10 +00:00
|
|
|
bfiles <- inRepo $ Git.pipeNullSplit
|
2011-06-23 03:24:14 +00:00
|
|
|
[Params "ls-tree --name-only -r -z", Param fullname]
|
2011-10-03 21:27:48 +00:00
|
|
|
jfiles <- getJournalledFiles
|
2011-06-23 15:37:26 +00:00
|
|
|
return $ jfiles ++ bfiles
|
|
|
|
|
|
|
|
{- Records content for a file in the branch to the journal.
|
|
|
|
-
|
|
|
|
- Using the journal, rather than immediatly staging content to the index
|
|
|
|
- avoids git needing to rewrite the index after every change. -}
|
|
|
|
setJournalFile :: FilePath -> String -> Annex ()
|
|
|
|
setJournalFile file content = do
|
2011-10-04 02:24:57 +00:00
|
|
|
g <- gitRepo
|
2011-11-02 19:09:19 +00:00
|
|
|
liftIO $ doRedo (write g) $ do
|
2011-06-23 15:37:26 +00:00
|
|
|
createDirectoryIfMissing True $ gitAnnexJournalDir g
|
|
|
|
createDirectoryIfMissing True $ gitAnnexTmpDir g
|
|
|
|
where
|
|
|
|
-- journal file is written atomically
|
|
|
|
write g = do
|
|
|
|
let jfile = journalFile g file
|
|
|
|
let tmpfile = gitAnnexTmpDir g </> takeFileName jfile
|
2011-06-30 04:35:51 +00:00
|
|
|
writeBinaryFile tmpfile content
|
2011-06-23 15:37:26 +00:00
|
|
|
renameFile tmpfile jfile
|
|
|
|
|
2011-10-03 20:32:36 +00:00
|
|
|
{- Gets any journalled content for a file in the branch. -}
|
2011-06-23 15:37:26 +00:00
|
|
|
getJournalFile :: FilePath -> Annex (Maybe String)
|
|
|
|
getJournalFile file = do
|
2011-10-04 02:24:57 +00:00
|
|
|
g <- gitRepo
|
2011-06-23 15:37:26 +00:00
|
|
|
liftIO $ catch (liftM Just . readFileStrict $ journalFile g file)
|
|
|
|
(const $ return Nothing)
|
|
|
|
|
2011-10-03 21:27:48 +00:00
|
|
|
{- List of files that have updated content in the journal. -}
|
|
|
|
getJournalledFiles :: Annex [FilePath]
|
|
|
|
getJournalledFiles = map fileJournal <$> getJournalFiles
|
2011-06-23 15:37:26 +00:00
|
|
|
|
2011-10-03 21:27:48 +00:00
|
|
|
{- List of existing journal files. -}
|
|
|
|
getJournalFiles :: Annex [FilePath]
|
|
|
|
getJournalFiles = do
|
2011-10-04 02:24:57 +00:00
|
|
|
g <- gitRepo
|
2011-06-23 15:37:26 +00:00
|
|
|
fs <- liftIO $ catch (getDirectoryContents $ gitAnnexJournalDir g)
|
|
|
|
(const $ return [])
|
2011-09-21 03:26:35 +00:00
|
|
|
return $ filter (`notElem` [".", ".."]) fs
|
2011-06-23 15:37:26 +00:00
|
|
|
|
2011-10-03 21:27:48 +00:00
|
|
|
{- Stages the specified journalfiles. -}
|
2011-10-09 20:19:09 +00:00
|
|
|
stageJournalFiles :: Annex ()
|
|
|
|
stageJournalFiles = do
|
|
|
|
fs <- getJournalFiles
|
2011-10-04 02:24:57 +00:00
|
|
|
g <- gitRepo
|
2011-10-03 21:27:48 +00:00
|
|
|
withIndex $ liftIO $ do
|
|
|
|
let dir = gitAnnexJournalDir g
|
|
|
|
let paths = map (dir </>) fs
|
|
|
|
-- inject all the journal files directly into git
|
|
|
|
-- in one quick command
|
2011-10-10 21:37:44 +00:00
|
|
|
(pid, fromh, toh) <- hPipeBoth "git" $ toCommand $ git_hash_object g
|
2011-10-03 21:27:48 +00:00
|
|
|
_ <- forkProcess $ do
|
|
|
|
hPutStr toh $ unlines paths
|
2011-07-05 17:26:59 +00:00
|
|
|
hClose toh
|
2011-10-03 21:27:48 +00:00
|
|
|
exitSuccess
|
|
|
|
hClose toh
|
|
|
|
s <- hGetContents fromh
|
|
|
|
-- update the index, also in just one command
|
|
|
|
Git.UnionMerge.update_index g $
|
|
|
|
index_lines (lines s) $ map fileJournal fs
|
|
|
|
hClose fromh
|
|
|
|
forceSuccess pid
|
|
|
|
mapM_ removeFile paths
|
|
|
|
where
|
|
|
|
index_lines shas = map genline . zip shas
|
2011-06-30 17:32:47 +00:00
|
|
|
genline (sha, file) = Git.UnionMerge.update_index_line sha file
|
2011-11-08 19:34:10 +00:00
|
|
|
git_hash_object g = Git.gitCommandLine
|
|
|
|
[Param "hash-object", Param "-w", Param "--stdin-paths"] g
|
2011-10-10 21:37:44 +00:00
|
|
|
|
2011-06-23 15:37:26 +00:00
|
|
|
|
2011-10-09 20:19:09 +00:00
|
|
|
{- Checks if there are changes in the journal. -}
|
|
|
|
journalDirty :: Annex Bool
|
|
|
|
journalDirty = not . null <$> getJournalFiles
|
|
|
|
|
2011-06-23 15:37:26 +00:00
|
|
|
{- Produces a filename to use in the journal for a file on the branch.
|
|
|
|
-
|
|
|
|
- The journal typically won't have a lot of files in it, so the hashing
|
|
|
|
- used in the branch is not necessary, and all the files are put directly
|
|
|
|
- in the journal directory.
|
|
|
|
-}
|
|
|
|
journalFile :: Git.Repo -> FilePath -> FilePath
|
|
|
|
journalFile repo file = gitAnnexJournalDir repo </> concatMap mangle file
|
|
|
|
where
|
|
|
|
mangle '/' = "_"
|
|
|
|
mangle '_' = "__"
|
|
|
|
mangle c = [c]
|
|
|
|
|
|
|
|
{- Converts a journal file (relative to the journal dir) back to the
|
|
|
|
- filename on the branch. -}
|
|
|
|
fileJournal :: FilePath -> FilePath
|
|
|
|
fileJournal = replace "//" "_" . replace "_" "/"
|
2011-10-03 20:32:36 +00:00
|
|
|
|
|
|
|
{- Runs an action that modifies the journal, using locking to avoid
|
|
|
|
- contention with other git-annex processes. -}
|
|
|
|
lockJournal :: Annex a -> Annex a
|
|
|
|
lockJournal a = do
|
2011-11-08 19:34:10 +00:00
|
|
|
file <- fromRepo $ gitAnnexJournalLock
|
2011-10-04 04:34:04 +00:00
|
|
|
bracketIO (lock file) unlock a
|
2011-10-03 22:20:29 +00:00
|
|
|
where
|
|
|
|
lock file = do
|
2011-11-02 19:09:19 +00:00
|
|
|
l <- doRedo (createFile file stdFileMode) $
|
|
|
|
createDirectoryIfMissing True $ takeDirectory file
|
2011-10-03 22:20:29 +00:00
|
|
|
waitToSetLock l (WriteLock, AbsoluteSeek, 0, 0)
|
|
|
|
return l
|
|
|
|
unlock = closeFd
|
2011-11-02 19:09:19 +00:00
|
|
|
|
|
|
|
{- Runs an action, catching failure and running something to fix it up, and
|
|
|
|
- retrying if necessary. -}
|
|
|
|
doRedo :: IO a -> IO b -> IO a
|
|
|
|
doRedo a b = catch a $ const $ b >> a
|