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-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,
|
2011-12-12 22:23:24 +00:00
|
|
|
name,
|
2011-06-24 15:59:34 +00:00
|
|
|
hasOrigin,
|
2011-12-12 22:23:24 +00:00
|
|
|
hasSibling,
|
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-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-12-12 21:38:46 +00:00
|
|
|
import Annex.BranchState
|
2011-12-12 22:03:28 +00:00
|
|
|
import Annex.Journal
|
2011-06-30 17:16:57 +00:00
|
|
|
import qualified Git
|
2011-06-30 17:32:47 +00:00
|
|
|
import qualified Git.UnionMerge
|
2011-12-12 22:23:24 +00:00
|
|
|
import qualified Git.Ref
|
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-21 21:39:45 +00:00
|
|
|
{- Name of the branch that is used to store git-annex's information. -}
|
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
|
|
|
name :: Git.Ref
|
|
|
|
name = Git.Ref "git-annex"
|
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-21 21:39:45 +00:00
|
|
|
{- Fully qualified name of the branch. -}
|
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
|
|
|
fullname :: Git.Ref
|
|
|
|
fullname = Git.Ref $ "refs/heads/" ++ show name
|
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
|
|
|
{- Branch's name in origin. -}
|
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
|
|
|
originname :: Git.Ref
|
|
|
|
originname = Git.Ref $ "origin/" ++ show name
|
2011-06-24 15:59:34 +00:00
|
|
|
|
2011-06-21 21:39:45 +00:00
|
|
|
{- Populates the branch's index file with the current branch contents.
|
|
|
|
-
|
slow, stupid, and safe index updating
Always merge the git-annex branch into .git/annex/index before making a
commit from the index.
This ensures that, when the branch has been changed in any way
(by a push being received, or changes pulled directly into it, or
even by the user checking it out, and committing a change), the index
reflects those changes.
This is much too slow; it needs to be optimised to only update the
index when the branch has really changed, not every time.
Also, there is an unhandled race, when a change is made to the branch
right after the index gets updated. I left it in for now because it's
unlikely and I didn't want to complicate things with additional locking
yet.
2011-12-11 18:51:20 +00:00
|
|
|
- This is only done when the index doesn't yet exist, and 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-16 05:46:46 +00:00
|
|
|
genIndex g = Git.UnionMerge.stream_update_index g
|
2011-11-16 03:28:01 +00:00
|
|
|
[Git.UnionMerge.ls_tree fullname g]
|
2011-06-21 21:39:45 +00:00
|
|
|
|
slow, stupid, and safe index updating
Always merge the git-annex branch into .git/annex/index before making a
commit from the index.
This ensures that, when the branch has been changed in any way
(by a push being received, or changes pulled directly into it, or
even by the user checking it out, and committing a change), the index
reflects those changes.
This is much too slow; it needs to be optimised to only update the
index when the branch has really changed, not every time.
Also, there is an unhandled race, when a change is made to the branch
right after the index gets updated. I left it in for now because it's
unlikely and I didn't want to complicate things with additional locking
yet.
2011-12-11 18:51:20 +00:00
|
|
|
{- Merges the specified branches into the index.
|
|
|
|
- Any changes staged in the index will be preserved. -}
|
|
|
|
mergeIndex :: [Git.Ref] -> Annex ()
|
|
|
|
mergeIndex branches = do
|
|
|
|
h <- catFileHandle
|
|
|
|
inRepo $ \g -> Git.UnionMerge.merge_index h g branches
|
|
|
|
|
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
|
|
|
{- Runs an action using the branch's index file. -}
|
|
|
|
withIndex :: Annex a -> Annex a
|
|
|
|
withIndex = withIndex' False
|
|
|
|
withIndex' :: Bool -> Annex a -> Annex a
|
|
|
|
withIndex' bootstrapping a = do
|
|
|
|
f <- fromRepo gitAnnexIndex
|
|
|
|
bracketIO (Git.useIndex f) id $ do
|
|
|
|
unlessM (liftIO $ doesFileExist f) $ do
|
|
|
|
unless bootstrapping create
|
|
|
|
liftIO $ createDirectoryIfMissing True $ takeDirectory f
|
|
|
|
unless bootstrapping $ inRepo genIndex
|
|
|
|
a
|
|
|
|
|
slow, stupid, and safe index updating
Always merge the git-annex branch into .git/annex/index before making a
commit from the index.
This ensures that, when the branch has been changed in any way
(by a push being received, or changes pulled directly into it, or
even by the user checking it out, and committing a change), the index
reflects those changes.
This is much too slow; it needs to be optimised to only update the
index when the branch has really changed, not every time.
Also, there is an unhandled race, when a change is made to the branch
right after the index gets updated. I left it in for now because it's
unlikely and I didn't want to complicate things with additional locking
yet.
2011-12-11 18:51:20 +00:00
|
|
|
{- Updates the branch's index to reflect the current contents of the branch.
|
2011-12-11 20:11:13 +00:00
|
|
|
- Any changes staged in the index will be preserved.
|
|
|
|
-
|
|
|
|
- Compares the ref stored in the lock file with the current
|
|
|
|
- ref of the branch to see if an update is needed.
|
|
|
|
-}
|
2011-12-12 07:30:47 +00:00
|
|
|
updateIndex :: Git.Ref -> Annex ()
|
|
|
|
updateIndex branchref = do
|
|
|
|
lock <- fromRepo gitAnnexIndexLock
|
|
|
|
lockref <- Git.Ref . firstLine <$>
|
|
|
|
liftIO (catchDefaultIO (readFileStrict lock) "")
|
|
|
|
when (lockref /= branchref) $ do
|
|
|
|
withIndex $ mergeIndex [fullname]
|
2011-12-12 22:23:24 +00:00
|
|
|
setIndexSha branchref
|
2011-12-11 20:11:13 +00:00
|
|
|
|
|
|
|
{- Record that the branch's index has been updated to correspond to a
|
|
|
|
- given ref of the branch. -}
|
2011-12-12 22:23:24 +00:00
|
|
|
setIndexSha :: Git.Ref -> Annex ()
|
|
|
|
setIndexSha ref = do
|
2011-12-11 20:11:13 +00:00
|
|
|
lock <- fromRepo gitAnnexIndexLock
|
|
|
|
liftIO $ writeFile lock $ show ref ++ "\n"
|
slow, stupid, and safe index updating
Always merge the git-annex branch into .git/annex/index before making a
commit from the index.
This ensures that, when the branch has been changed in any way
(by a push being received, or changes pulled directly into it, or
even by the user checking it out, and committing a change), the index
reflects those changes.
This is much too slow; it needs to be optimised to only update the
index when the branch has really changed, not every time.
Also, there is an unhandled race, when a change is made to the branch
right after the index gets updated. I left it in for now because it's
unlikely and I didn't want to complicate things with additional locking
yet.
2011-12-11 18:51:20 +00:00
|
|
|
|
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
|
|
|
{- Commits the staged changes in the index to the branch.
|
|
|
|
-
|
2011-12-12 21:24:12 +00:00
|
|
|
- Ensures that the branch's index file is first updated to the state
|
|
|
|
- of the brannch at branchref, before running the commit action. This
|
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
|
|
|
- is needed because the branch may have had changes pushed to it, that
|
|
|
|
- are not yet reflected in the index.
|
|
|
|
-
|
|
|
|
- Also safely handles a race that can occur if a change is being pushed
|
|
|
|
- into the branch at the same time. When the race happens, the commit will
|
|
|
|
- be made on top of the newly pushed change, but without the index file
|
|
|
|
- being updated to include it. The result is that the newly pushed
|
|
|
|
- change is reverted. This race is detected and another commit made
|
|
|
|
- to fix it.
|
2011-12-12 21:24:12 +00:00
|
|
|
-
|
|
|
|
- The branchref value can have been obtained using getBranch at any
|
|
|
|
- previous point, though getting it a long time ago makes the race
|
|
|
|
- more likely to occur.
|
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
|
|
|
-}
|
2011-12-12 07:30:47 +00:00
|
|
|
commitBranch :: Git.Ref -> String -> [Git.Ref] -> Annex ()
|
|
|
|
commitBranch branchref message parents = do
|
|
|
|
updateIndex branchref
|
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
|
|
|
committedref <- inRepo $ Git.commit message fullname parents
|
2011-12-12 22:23:24 +00:00
|
|
|
setIndexSha committedref
|
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
|
|
|
parentrefs <- commitparents <$> catObject committedref
|
2011-12-12 07:30:47 +00:00
|
|
|
when (racedetected branchref parentrefs) $
|
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
|
|
|
fixrace committedref parentrefs
|
|
|
|
where
|
|
|
|
-- look for "parent ref" lines and return the refs
|
|
|
|
commitparents = map (Git.Ref . snd) . filter isparent .
|
|
|
|
map (toassoc . L.unpack) . L.lines
|
|
|
|
toassoc = separate (== ' ')
|
|
|
|
isparent (k,_) = k == "parent"
|
|
|
|
|
|
|
|
{- The race can be detected by checking the commit's
|
|
|
|
- parent, which will be the newly pushed branch,
|
|
|
|
- instead of the expected ref that the index was updated to. -}
|
2011-12-12 07:30:47 +00:00
|
|
|
racedetected expectedref parentrefs
|
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
|
|
|
| expectedref `elem` parentrefs = False -- good parent
|
|
|
|
| otherwise = True -- race!
|
|
|
|
|
|
|
|
{- To recover from the race, union merge the lost refs
|
|
|
|
- into the index, and recommit on top of the bad commit. -}
|
|
|
|
fixrace committedref lostrefs = do
|
|
|
|
mergeIndex lostrefs
|
2011-12-12 07:30:47 +00:00
|
|
|
commitBranch committedref racemessage [committedref]
|
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
|
|
|
|
|
|
|
racemessage = message ++ " (recovery from race)"
|
2011-06-21 21:39:45 +00:00
|
|
|
|
slow, stupid, and safe index updating
Always merge the git-annex branch into .git/annex/index before making a
commit from the index.
This ensures that, when the branch has been changed in any way
(by a push being received, or changes pulled directly into it, or
even by the user checking it out, and committing a change), the index
reflects those changes.
This is much too slow; it needs to be optimised to only update the
index when the branch has really changed, not every time.
Also, there is an unhandled race, when a change is made to the branch
right after the index gets updated. I left it in for now because it's
unlikely and I didn't want to complicate things with additional locking
yet.
2011-12-11 18:51:20 +00:00
|
|
|
{- Runs an action using the branch's index file, first making sure that
|
|
|
|
- the branch and index are up-to-date. -}
|
2011-06-22 19:58:30 +00:00
|
|
|
withIndexUpdate :: Annex a -> Annex a
|
|
|
|
withIndexUpdate a = update >> withIndex a
|
|
|
|
|
|
|
|
{- Creates the branch, if it does not already exist. -}
|
|
|
|
create :: Annex ()
|
2011-12-12 07:30:47 +00:00
|
|
|
create = do
|
|
|
|
_ <- getBranch
|
|
|
|
return ()
|
|
|
|
|
|
|
|
{- Returns the ref of the branch, creating it first if necessary. -}
|
|
|
|
getBranch :: Annex (Git.Ref)
|
2011-12-12 22:23:24 +00:00
|
|
|
getBranch = maybe (hasOrigin >>= go >>= use) (return) =<< branchsha
|
2011-12-11 20:11:13 +00:00
|
|
|
where
|
|
|
|
go True = do
|
|
|
|
inRepo $ Git.run "branch"
|
|
|
|
[Param $ show name, Param $ show originname]
|
2011-12-12 07:30:47 +00:00
|
|
|
fromMaybe (error $ "failed to create " ++ show name)
|
2011-12-12 22:23:24 +00:00
|
|
|
<$> branchsha
|
2011-12-12 07:30:47 +00:00
|
|
|
go False = withIndex' True $ do
|
|
|
|
inRepo $ Git.commit "branch created" fullname []
|
2011-12-12 22:23:24 +00:00
|
|
|
use sha = do
|
|
|
|
setIndexSha sha
|
|
|
|
return sha
|
|
|
|
branchsha = inRepo $ Git.Ref.sha 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
|
2011-12-12 22:03:28 +00:00
|
|
|
stageJournal
|
2011-12-12 07:30:47 +00:00
|
|
|
ref <- getBranch
|
|
|
|
withIndex $ commitBranch ref message [fullname]
|
2011-06-22 23:48:04 +00:00
|
|
|
|
slow, stupid, and safe index updating
Always merge the git-annex branch into .git/annex/index before making a
commit from the index.
This ensures that, when the branch has been changed in any way
(by a push being received, or changes pulled directly into it, or
even by the user checking it out, and committing a change), the index
reflects those changes.
This is much too slow; it needs to be optimised to only update the
index when the branch has really changed, not every time.
Also, there is an unhandled race, when a change is made to the branch
right after the index gets updated. I left it in for now because it's
unlikely and I didn't want to complicate things with additional locking
yet.
2011-12-11 18:51:20 +00:00
|
|
|
{- Ensures that the branch and index are 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
|
|
|
-
|
2011-11-12 18:51:19 +00:00
|
|
|
- (It would be cleaner to handle the merge by updating the journal, not the
|
|
|
|
- index, with changes from the 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
|
|
|
-
|
2011-12-12 01:40:36 +00:00
|
|
|
- The branch is fast-forwarded if possible, otherwise a merge commit is
|
|
|
|
- made.
|
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-12-12 21:38:46 +00:00
|
|
|
update = runUpdateOnce $ do
|
2011-12-12 07:30:47 +00:00
|
|
|
-- ensure branch exists, and get its current ref
|
|
|
|
branchref <- getBranch
|
2011-10-07 17:59:34 +00:00
|
|
|
-- check what needs updating before taking the lock
|
2011-10-09 20:19:09 +00:00
|
|
|
dirty <- journalDirty
|
2011-12-12 06:31:07 +00:00
|
|
|
c <- filterM (changedBranch fullname . snd) =<< siblingBranches
|
2011-10-07 17:59:34 +00:00
|
|
|
let (refs, branches) = unzip c
|
2011-12-12 01:40:36 +00:00
|
|
|
if (not dirty && null refs)
|
2011-12-12 07:30:47 +00:00
|
|
|
then updateIndex branchref
|
2011-12-12 01:40:36 +00:00
|
|
|
else withIndex $ lockJournal $ do
|
2011-12-12 22:03:28 +00:00
|
|
|
when dirty stageJournal
|
2011-12-12 01:40:36 +00:00
|
|
|
let merge_desc = if null branches
|
|
|
|
then "update"
|
|
|
|
else "merging " ++
|
2011-12-12 22:23:24 +00:00
|
|
|
unwords (map Git.Ref.describe branches) ++
|
2011-12-12 01:40:36 +00:00
|
|
|
" into " ++ show name
|
|
|
|
unless (null branches) $ do
|
|
|
|
showSideAction merge_desc
|
|
|
|
mergeIndex branches
|
|
|
|
ff <- if dirty then return False else tryFastForwardTo refs
|
|
|
|
if ff
|
2011-12-12 07:30:47 +00:00
|
|
|
then updateIndex branchref
|
|
|
|
else commitBranch branchref merge_desc
|
|
|
|
(nub $ fullname:refs)
|
2011-12-12 01:40:36 +00:00
|
|
|
invalidateCache
|
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. -}
|
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
|
|
|
changedBranch :: Git.Branch -> Git.Branch -> Annex Bool
|
2011-12-12 06:31:07 +00:00
|
|
|
changedBranch origbranch newbranch
|
|
|
|
| origbranch == newbranch = return False
|
|
|
|
| otherwise = not . L.null <$> diffs
|
2011-11-08 19:34:10 +00:00
|
|
|
where
|
|
|
|
diffs = inRepo $ Git.pipeRead
|
|
|
|
[ Param "log"
|
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
|
|
|
, Param (show origbranch ++ ".." ++ show newbranch)
|
2011-11-08 19:34:10 +00:00
|
|
|
, 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.
|
|
|
|
-}
|
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
|
|
|
tryFastForwardTo :: [Git.Ref] -> Annex Bool
|
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
|
|
|
tryFastForwardTo [] = return True
|
|
|
|
tryFastForwardTo (first:rest) = do
|
|
|
|
-- First, check that the git-annex branch does not contain any
|
2011-11-30 16:01:15 +00:00
|
|
|
-- new commits that are not in the first other branch. If it does,
|
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
|
|
|
-- 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-30 16:01:15 +00:00
|
|
|
inRepo $ Git.run "update-ref"
|
|
|
|
[Param $ show fullname, Param $ show 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-08-17 18:14:43 +00:00
|
|
|
{- Does origin/git-annex exist? -}
|
|
|
|
hasOrigin :: Annex Bool
|
2011-12-12 22:23:24 +00:00
|
|
|
hasOrigin = inRepo $ Git.Ref.exists originname
|
2011-08-17 18:14:43 +00:00
|
|
|
|
2011-12-12 22:23:24 +00:00
|
|
|
{- Does the git-annex branch or a sibling foo/git-annex branch exist? -}
|
|
|
|
hasSibling :: Annex Bool
|
|
|
|
hasSibling = 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. -}
|
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
|
|
|
siblingBranches :: Annex [(Git.Ref, Git.Branch)]
|
2011-12-12 22:23:24 +00:00
|
|
|
siblingBranches = inRepo $ Git.Ref.matching name
|
2011-08-17 18:14:43 +00:00
|
|
|
|
2011-11-12 19:15:57 +00:00
|
|
|
{- Applies a function to modifiy the content of a file.
|
|
|
|
-
|
|
|
|
- Note that this does not cause the branch to be merged, it only
|
|
|
|
- modifes the current content of the file on the branch.
|
|
|
|
-}
|
2011-10-03 19:41:25 +00:00
|
|
|
change :: FilePath -> (String -> String) -> Annex ()
|
2011-11-12 19:15:57 +00:00
|
|
|
change file a = lockJournal $ getStale file >>= return . a >>= set file
|
2011-10-03 19:41:25 +00:00
|
|
|
|
2011-12-12 22:03:28 +00:00
|
|
|
{- Records new content of a file into the journal and cache. -}
|
2011-10-03 19:41:25 +00:00
|
|
|
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-11-12 19:15:57 +00:00
|
|
|
get = get' False
|
|
|
|
|
|
|
|
{- Like get, but does not merge the branch, so the info returned may not
|
|
|
|
- reflect changes in remotes. (Changing the value this returns, and then
|
|
|
|
- merging is always the same as using get, and then changing its value.) -}
|
|
|
|
getStale :: FilePath -> Annex String
|
|
|
|
getStale = get' True
|
|
|
|
|
|
|
|
get' :: Bool -> FilePath -> Annex String
|
|
|
|
get' staleok file = fromcache =<< getCache file
|
2011-10-10 21:37:44 +00:00
|
|
|
where
|
|
|
|
fromcache (Just content) = return content
|
|
|
|
fromcache Nothing = fromjournal =<< getJournalFile file
|
|
|
|
fromjournal (Just content) = cache content
|
2011-11-12 19:15:57 +00:00
|
|
|
fromjournal Nothing
|
|
|
|
| staleok = withIndex frombranch
|
|
|
|
| otherwise = withIndexUpdate $ frombranch >>= cache
|
2011-11-12 21:45:12 +00:00
|
|
|
frombranch = L.unpack <$> catFile fullname file
|
2011-10-10 21:37:44 +00:00
|
|
|
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
|
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
|
|
|
[Params "ls-tree --name-only -r -z", Param $ show fullname]
|
2011-10-03 21:27:48 +00:00
|
|
|
jfiles <- getJournalledFiles
|
2011-06-23 15:37:26 +00:00
|
|
|
return $ jfiles ++ bfiles
|
|
|
|
|
2011-12-12 22:03:28 +00:00
|
|
|
{- Stages the journal into the index. -}
|
|
|
|
stageJournal :: Annex ()
|
|
|
|
stageJournal = do
|
2011-10-09 20:19:09 +00:00
|
|
|
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
|
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
|
|
|
shas <- map Git.Ref . lines <$> hGetContents fromh
|
2011-10-03 21:27:48 +00:00
|
|
|
-- update the index, also in just one command
|
|
|
|
Git.UnionMerge.update_index g $
|
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
|
|
|
index_lines shas (map fileJournal fs)
|
2011-10-03 21:27:48 +00:00
|
|
|
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-11 05:52:58 +00:00
|
|
|
git_hash_object = Git.gitCommandLine
|
|
|
|
[Param "hash-object", Param "-w", Param "--stdin-paths"]
|