2011-06-21 18:09:06 +00:00
|
|
|
{- git-union-merge library
|
|
|
|
-
|
|
|
|
- Copyright 2011 Joey Hess <joey@kitenet.net>
|
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
2011-06-30 17:32:47 +00:00
|
|
|
module Git.UnionMerge (
|
2011-06-21 23:09:20 +00:00
|
|
|
merge,
|
2011-10-07 17:17:54 +00:00
|
|
|
merge_index,
|
2011-06-23 15:37:26 +00:00
|
|
|
update_index,
|
2011-11-16 05:46:46 +00:00
|
|
|
stream_update_index,
|
2011-06-23 21:38:27 +00:00
|
|
|
update_index_line,
|
|
|
|
ls_tree
|
2011-06-21 18:09:06 +00:00
|
|
|
) where
|
|
|
|
|
|
|
|
import System.Cmd.Utils
|
2012-02-01 20:05:02 +00:00
|
|
|
import qualified Data.Text.Lazy as L
|
|
|
|
import qualified Data.Text.Lazy.Encoding as L
|
2011-12-12 05:33:02 +00:00
|
|
|
import qualified Data.Set as S
|
2011-06-21 18:09:06 +00:00
|
|
|
|
2011-10-07 17:17:54 +00:00
|
|
|
import Common
|
2011-06-30 17:32:47 +00:00
|
|
|
import Git
|
2011-12-14 19:30:14 +00:00
|
|
|
import Git.Sha
|
2011-11-12 21:45:12 +00:00
|
|
|
import Git.CatFile
|
2011-12-14 19:56:11 +00:00
|
|
|
import Git.Command
|
2011-06-21 18:09:06 +00:00
|
|
|
|
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
|
|
|
type Streamer = (String -> IO ()) -> IO ()
|
|
|
|
|
2011-06-21 23:52:40 +00:00
|
|
|
{- Performs a union merge between two branches, staging it in the index.
|
|
|
|
- Any previously staged changes in the index will be lost.
|
2011-06-21 21:39:45 +00:00
|
|
|
-
|
2011-12-14 19:30:14 +00:00
|
|
|
- Should be run with a temporary index file configured by useIndex.
|
2011-06-21 21:39:45 +00:00
|
|
|
-}
|
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
|
|
|
merge :: Ref -> Ref -> Repo -> IO ()
|
2011-11-08 19:34:10 +00:00
|
|
|
merge x y repo = do
|
2011-11-12 21:45:12 +00:00
|
|
|
h <- catFileStart repo
|
2011-11-16 05:46:46 +00:00
|
|
|
stream_update_index repo
|
2011-11-16 03:28:01 +00:00
|
|
|
[ ls_tree x repo
|
|
|
|
, merge_trees x y h repo
|
|
|
|
]
|
2011-11-12 21:45:12 +00:00
|
|
|
catFileStop h
|
2011-10-07 17:17:54 +00:00
|
|
|
|
|
|
|
{- Merges a list of branches into the index. Previously staged changed in
|
|
|
|
- the index are preserved (and participate in the merge). -}
|
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
|
|
|
merge_index :: CatFileHandle -> Repo -> [Ref] -> IO ()
|
2011-11-12 21:45:12 +00:00
|
|
|
merge_index h repo bs =
|
2011-11-16 05:46:46 +00:00
|
|
|
stream_update_index repo $ map (\b -> merge_tree_index b h repo) bs
|
2011-06-21 18:09:06 +00:00
|
|
|
|
2011-11-16 03:28:01 +00:00
|
|
|
{- Feeds content into update-index. Later items in the list can override
|
2011-06-21 23:52:40 +00:00
|
|
|
- earlier ones, so the list can be generated from any combination of
|
2011-06-22 17:59:42 +00:00
|
|
|
- ls_tree, merge_trees, and merge_tree_index. -}
|
2011-11-16 03:48:50 +00:00
|
|
|
update_index :: Repo -> [String] -> IO ()
|
2011-12-09 05:57:13 +00:00
|
|
|
update_index repo ls = stream_update_index repo [(`mapM_` ls)]
|
2011-11-16 03:48:50 +00:00
|
|
|
|
|
|
|
{- Streams content into update-index. -}
|
2011-11-16 05:46:46 +00:00
|
|
|
stream_update_index :: Repo -> [Streamer] -> IO ()
|
|
|
|
stream_update_index repo as = do
|
2011-12-14 19:30:14 +00:00
|
|
|
(p, h) <- hPipeTo "git" (toCommand $ gitCommandLine params repo)
|
2012-02-04 17:03:33 +00:00
|
|
|
fileEncoding h
|
2011-11-16 03:48:50 +00:00
|
|
|
forM_ as (stream h)
|
2011-11-16 02:01:32 +00:00
|
|
|
hClose h
|
|
|
|
forceSuccess p
|
2011-06-21 18:09:06 +00:00
|
|
|
where
|
2011-11-16 02:01:32 +00:00
|
|
|
params = map Param ["update-index", "-z", "--index-info"]
|
2011-11-16 03:48:50 +00:00
|
|
|
stream h a = a (streamer h)
|
|
|
|
streamer h s = do
|
|
|
|
hPutStr h s
|
|
|
|
hPutStr h "\0"
|
2011-11-16 03:28:01 +00:00
|
|
|
|
2011-06-23 15:37:26 +00:00
|
|
|
{- Generates a line suitable to be fed into update-index, to add
|
|
|
|
- a given file with a given sha. -}
|
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
|
|
|
update_index_line :: Sha -> FilePath -> String
|
|
|
|
update_index_line sha file = "100644 blob " ++ show sha ++ "\t" ++ file
|
2011-06-23 15:37:26 +00:00
|
|
|
|
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
|
|
|
{- Gets the current tree for a ref. -}
|
|
|
|
ls_tree :: Ref -> Repo -> Streamer
|
|
|
|
ls_tree (Ref x) repo streamer = mapM_ streamer =<< pipeNullSplit params repo
|
2011-11-08 19:34:10 +00:00
|
|
|
where
|
|
|
|
params = map Param ["ls-tree", "-z", "-r", "--full-tree", x]
|
2011-06-21 23:52:40 +00:00
|
|
|
|
|
|
|
{- For merging two trees. -}
|
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
|
|
|
merge_trees :: Ref -> Ref -> CatFileHandle -> Repo -> Streamer
|
|
|
|
merge_trees (Ref x) (Ref y) h = calc_merge h $ "diff-tree":diff_opts ++ [x, y]
|
2011-06-21 23:52:40 +00:00
|
|
|
|
|
|
|
{- For merging a single tree into the index. -}
|
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
|
|
|
merge_tree_index :: Ref -> CatFileHandle -> Repo -> Streamer
|
2012-02-09 21:35:36 +00:00
|
|
|
merge_tree_index (Ref x) h = calc_merge h $
|
|
|
|
"diff-index" : diff_opts ++ ["--cached", x]
|
2011-06-23 21:38:27 +00:00
|
|
|
|
|
|
|
diff_opts :: [String]
|
|
|
|
diff_opts = ["--raw", "-z", "-r", "--no-renames", "-l0"]
|
2011-06-21 23:52:40 +00:00
|
|
|
|
|
|
|
{- Calculates how to perform a merge, using git to get a raw diff,
|
2012-02-09 21:35:36 +00:00
|
|
|
- and generating update-index input. -}
|
2011-11-16 03:48:50 +00:00
|
|
|
calc_merge :: CatFileHandle -> [String] -> Repo -> Streamer
|
|
|
|
calc_merge ch differ repo streamer = gendiff >>= go
|
2011-06-21 23:52:40 +00:00
|
|
|
where
|
2011-11-16 03:48:50 +00:00
|
|
|
gendiff = pipeNullSplit (map Param differ) repo
|
2012-04-22 03:32:33 +00:00
|
|
|
go [] = noop
|
2011-11-16 03:28:01 +00:00
|
|
|
go (info:file:rest) = mergeFile info file ch repo >>=
|
2011-11-16 03:48:50 +00:00
|
|
|
maybe (go rest) (\l -> streamer l >> go rest)
|
2011-11-16 03:28:01 +00:00
|
|
|
go (_:[]) = error "calc_merge parse error"
|
2011-06-22 17:59:42 +00:00
|
|
|
|
|
|
|
{- Given an info line from a git raw diff, and the filename, generates
|
2012-02-09 21:35:36 +00:00
|
|
|
- a line suitable for update-index that union merges the two sides of the
|
2011-06-22 17:59:42 +00:00
|
|
|
- diff. -}
|
2011-11-16 03:28:01 +00:00
|
|
|
mergeFile :: String -> FilePath -> CatFileHandle -> Repo -> IO (Maybe String)
|
2012-01-06 21:24:03 +00:00
|
|
|
mergeFile info file h repo = case filter (/= nullSha) [Ref asha, Ref bsha] of
|
2011-06-22 17:59:42 +00:00
|
|
|
[] -> return Nothing
|
2011-12-12 05:33:02 +00:00
|
|
|
(sha:[]) -> use sha
|
support all filename encodings with ghc 7.4
Under ghc 7.4, this seems to be able to handle all filename encodings
again. Including filename encodings that do not match the LANG setting.
I think this will not work with earlier versions of ghc, it uses some ghc
internals.
Turns out that ghc 7.4 has a special filesystem encoding that it uses when
reading/writing filenames (as FilePaths). This encoding is documented
to allow "arbitrary undecodable bytes to be round-tripped through it".
So, to get FilePaths from eg, git ls-files, set the Handle that is reading
from git to use this encoding. Then things basically just work.
However, I have not found a way to make Text read using this encoding.
Text really does assume unicode. So I had to switch back to using String
when reading/writing data to git. Which is a pity, because it's some
percent slower, but at least it works.
Note that stdout and stderr also have to be set to this encoding, or
printing out filenames that contain undecodable bytes causes a crash.
IMHO this is a misfeature in ghc, that the user can pass you a filename,
which you can readFile, etc, but that default, putStr of filename may
cause a crash!
Git.CheckAttr gave me special trouble, because the filenames I got back
from git, after feeding them in, had further encoding breakage.
Rather than try to deal with that, I just zip up the input filenames
with the attributes. Which must be returned in the same order queried
for this to work.
Also of note is an apparent GHC bug I worked around in Git.CheckAttr. It
used to forkProcess and feed git from the child process. Unfortunatly,
after this forkProcess, accessing the `files` variable from the parent
returns []. Not the value that was passed into the function. This screams
of a bad bug, that's clobbering a variable, but for now I just avoid
forkProcess there to work around it. That forkProcess was itself only added
because of a ghc bug, #624389. I've confirmed that the test case for that
bug doesn't reproduce it with ghc 7.4. So that's ok, except for the new ghc
bug I have not isolated and reported. Why does this simple bit of code
magnet the ghc bugs? :)
Also, the symlink touching code is currently broken, when used on utf-8
filenames in a non-utf-8 locale, or probably on any filename containing
undecodable bytes, and I temporarily commented it out.
2012-02-03 19:12:41 +00:00
|
|
|
shas -> use =<< either return (hashObject repo . unlines) =<<
|
2011-12-12 05:33:02 +00:00
|
|
|
calcMerge . zip shas <$> mapM getcontents shas
|
2011-06-22 17:59:42 +00:00
|
|
|
where
|
2011-12-12 03:02:25 +00:00
|
|
|
[_colonmode, _bmode, asha, bsha, _status] = words info
|
support all filename encodings with ghc 7.4
Under ghc 7.4, this seems to be able to handle all filename encodings
again. Including filename encodings that do not match the LANG setting.
I think this will not work with earlier versions of ghc, it uses some ghc
internals.
Turns out that ghc 7.4 has a special filesystem encoding that it uses when
reading/writing filenames (as FilePaths). This encoding is documented
to allow "arbitrary undecodable bytes to be round-tripped through it".
So, to get FilePaths from eg, git ls-files, set the Handle that is reading
from git to use this encoding. Then things basically just work.
However, I have not found a way to make Text read using this encoding.
Text really does assume unicode. So I had to switch back to using String
when reading/writing data to git. Which is a pity, because it's some
percent slower, but at least it works.
Note that stdout and stderr also have to be set to this encoding, or
printing out filenames that contain undecodable bytes causes a crash.
IMHO this is a misfeature in ghc, that the user can pass you a filename,
which you can readFile, etc, but that default, putStr of filename may
cause a crash!
Git.CheckAttr gave me special trouble, because the filenames I got back
from git, after feeding them in, had further encoding breakage.
Rather than try to deal with that, I just zip up the input filenames
with the attributes. Which must be returned in the same order queried
for this to work.
Also of note is an apparent GHC bug I worked around in Git.CheckAttr. It
used to forkProcess and feed git from the child process. Unfortunatly,
after this forkProcess, accessing the `files` variable from the parent
returns []. Not the value that was passed into the function. This screams
of a bad bug, that's clobbering a variable, but for now I just avoid
forkProcess there to work around it. That forkProcess was itself only added
because of a ghc bug, #624389. I've confirmed that the test case for that
bug doesn't reproduce it with ghc 7.4. So that's ok, except for the new ghc
bug I have not isolated and reported. Why does this simple bit of code
magnet the ghc bugs? :)
Also, the symlink touching code is currently broken, when used on utf-8
filenames in a non-utf-8 locale, or probably on any filename containing
undecodable bytes, and I temporarily commented it out.
2012-02-03 19:12:41 +00:00
|
|
|
getcontents s = map L.unpack . L.lines .
|
|
|
|
L.decodeUtf8 <$> catObject h s
|
2011-12-12 05:33:02 +00:00
|
|
|
use sha = return $ Just $ update_index_line sha file
|
2011-12-12 04:48:25 +00:00
|
|
|
|
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
|
|
|
{- Injects some content into git, returning its Sha. -}
|
support all filename encodings with ghc 7.4
Under ghc 7.4, this seems to be able to handle all filename encodings
again. Including filename encodings that do not match the LANG setting.
I think this will not work with earlier versions of ghc, it uses some ghc
internals.
Turns out that ghc 7.4 has a special filesystem encoding that it uses when
reading/writing filenames (as FilePaths). This encoding is documented
to allow "arbitrary undecodable bytes to be round-tripped through it".
So, to get FilePaths from eg, git ls-files, set the Handle that is reading
from git to use this encoding. Then things basically just work.
However, I have not found a way to make Text read using this encoding.
Text really does assume unicode. So I had to switch back to using String
when reading/writing data to git. Which is a pity, because it's some
percent slower, but at least it works.
Note that stdout and stderr also have to be set to this encoding, or
printing out filenames that contain undecodable bytes causes a crash.
IMHO this is a misfeature in ghc, that the user can pass you a filename,
which you can readFile, etc, but that default, putStr of filename may
cause a crash!
Git.CheckAttr gave me special trouble, because the filenames I got back
from git, after feeding them in, had further encoding breakage.
Rather than try to deal with that, I just zip up the input filenames
with the attributes. Which must be returned in the same order queried
for this to work.
Also of note is an apparent GHC bug I worked around in Git.CheckAttr. It
used to forkProcess and feed git from the child process. Unfortunatly,
after this forkProcess, accessing the `files` variable from the parent
returns []. Not the value that was passed into the function. This screams
of a bad bug, that's clobbering a variable, but for now I just avoid
forkProcess there to work around it. That forkProcess was itself only added
because of a ghc bug, #624389. I've confirmed that the test case for that
bug doesn't reproduce it with ghc 7.4. So that's ok, except for the new ghc
bug I have not isolated and reported. Why does this simple bit of code
magnet the ghc bugs? :)
Also, the symlink touching code is currently broken, when used on utf-8
filenames in a non-utf-8 locale, or probably on any filename containing
undecodable bytes, and I temporarily commented it out.
2012-02-03 19:12:41 +00:00
|
|
|
hashObject :: Repo -> String -> IO Sha
|
2011-12-12 04:48:25 +00:00
|
|
|
hashObject repo content = getSha subcmd $ do
|
2011-11-16 02:40:40 +00:00
|
|
|
(h, s) <- pipeWriteRead (map Param params) content repo
|
support all filename encodings with ghc 7.4
Under ghc 7.4, this seems to be able to handle all filename encodings
again. Including filename encodings that do not match the LANG setting.
I think this will not work with earlier versions of ghc, it uses some ghc
internals.
Turns out that ghc 7.4 has a special filesystem encoding that it uses when
reading/writing filenames (as FilePaths). This encoding is documented
to allow "arbitrary undecodable bytes to be round-tripped through it".
So, to get FilePaths from eg, git ls-files, set the Handle that is reading
from git to use this encoding. Then things basically just work.
However, I have not found a way to make Text read using this encoding.
Text really does assume unicode. So I had to switch back to using String
when reading/writing data to git. Which is a pity, because it's some
percent slower, but at least it works.
Note that stdout and stderr also have to be set to this encoding, or
printing out filenames that contain undecodable bytes causes a crash.
IMHO this is a misfeature in ghc, that the user can pass you a filename,
which you can readFile, etc, but that default, putStr of filename may
cause a crash!
Git.CheckAttr gave me special trouble, because the filenames I got back
from git, after feeding them in, had further encoding breakage.
Rather than try to deal with that, I just zip up the input filenames
with the attributes. Which must be returned in the same order queried
for this to work.
Also of note is an apparent GHC bug I worked around in Git.CheckAttr. It
used to forkProcess and feed git from the child process. Unfortunatly,
after this forkProcess, accessing the `files` variable from the parent
returns []. Not the value that was passed into the function. This screams
of a bad bug, that's clobbering a variable, but for now I just avoid
forkProcess there to work around it. That forkProcess was itself only added
because of a ghc bug, #624389. I've confirmed that the test case for that
bug doesn't reproduce it with ghc 7.4. So that's ok, except for the new ghc
bug I have not isolated and reported. Why does this simple bit of code
magnet the ghc bugs? :)
Also, the symlink touching code is currently broken, when used on utf-8
filenames in a non-utf-8 locale, or probably on any filename containing
undecodable bytes, and I temporarily commented it out.
2012-02-03 19:12:41 +00:00
|
|
|
length s `seq` do
|
2011-11-16 02:40:40 +00:00
|
|
|
forceSuccess h
|
|
|
|
reap -- XXX unsure why this is needed
|
support all filename encodings with ghc 7.4
Under ghc 7.4, this seems to be able to handle all filename encodings
again. Including filename encodings that do not match the LANG setting.
I think this will not work with earlier versions of ghc, it uses some ghc
internals.
Turns out that ghc 7.4 has a special filesystem encoding that it uses when
reading/writing filenames (as FilePaths). This encoding is documented
to allow "arbitrary undecodable bytes to be round-tripped through it".
So, to get FilePaths from eg, git ls-files, set the Handle that is reading
from git to use this encoding. Then things basically just work.
However, I have not found a way to make Text read using this encoding.
Text really does assume unicode. So I had to switch back to using String
when reading/writing data to git. Which is a pity, because it's some
percent slower, but at least it works.
Note that stdout and stderr also have to be set to this encoding, or
printing out filenames that contain undecodable bytes causes a crash.
IMHO this is a misfeature in ghc, that the user can pass you a filename,
which you can readFile, etc, but that default, putStr of filename may
cause a crash!
Git.CheckAttr gave me special trouble, because the filenames I got back
from git, after feeding them in, had further encoding breakage.
Rather than try to deal with that, I just zip up the input filenames
with the attributes. Which must be returned in the same order queried
for this to work.
Also of note is an apparent GHC bug I worked around in Git.CheckAttr. It
used to forkProcess and feed git from the child process. Unfortunatly,
after this forkProcess, accessing the `files` variable from the parent
returns []. Not the value that was passed into the function. This screams
of a bad bug, that's clobbering a variable, but for now I just avoid
forkProcess there to work around it. That forkProcess was itself only added
because of a ghc bug, #624389. I've confirmed that the test case for that
bug doesn't reproduce it with ghc 7.4. So that's ok, except for the new ghc
bug I have not isolated and reported. Why does this simple bit of code
magnet the ghc bugs? :)
Also, the symlink touching code is currently broken, when used on utf-8
filenames in a non-utf-8 locale, or probably on any filename containing
undecodable bytes, and I temporarily commented it out.
2012-02-03 19:12:41 +00:00
|
|
|
return s
|
2011-11-16 02:40:40 +00:00
|
|
|
where
|
|
|
|
subcmd = "hash-object"
|
|
|
|
params = [subcmd, "-w", "--stdin"]
|
2011-12-12 05:33:02 +00:00
|
|
|
|
|
|
|
{- Calculates a union merge between a list of refs, with contents.
|
|
|
|
-
|
|
|
|
- When possible, reuses the content of an existing ref, rather than
|
|
|
|
- generating new content.
|
|
|
|
-}
|
support all filename encodings with ghc 7.4
Under ghc 7.4, this seems to be able to handle all filename encodings
again. Including filename encodings that do not match the LANG setting.
I think this will not work with earlier versions of ghc, it uses some ghc
internals.
Turns out that ghc 7.4 has a special filesystem encoding that it uses when
reading/writing filenames (as FilePaths). This encoding is documented
to allow "arbitrary undecodable bytes to be round-tripped through it".
So, to get FilePaths from eg, git ls-files, set the Handle that is reading
from git to use this encoding. Then things basically just work.
However, I have not found a way to make Text read using this encoding.
Text really does assume unicode. So I had to switch back to using String
when reading/writing data to git. Which is a pity, because it's some
percent slower, but at least it works.
Note that stdout and stderr also have to be set to this encoding, or
printing out filenames that contain undecodable bytes causes a crash.
IMHO this is a misfeature in ghc, that the user can pass you a filename,
which you can readFile, etc, but that default, putStr of filename may
cause a crash!
Git.CheckAttr gave me special trouble, because the filenames I got back
from git, after feeding them in, had further encoding breakage.
Rather than try to deal with that, I just zip up the input filenames
with the attributes. Which must be returned in the same order queried
for this to work.
Also of note is an apparent GHC bug I worked around in Git.CheckAttr. It
used to forkProcess and feed git from the child process. Unfortunatly,
after this forkProcess, accessing the `files` variable from the parent
returns []. Not the value that was passed into the function. This screams
of a bad bug, that's clobbering a variable, but for now I just avoid
forkProcess there to work around it. That forkProcess was itself only added
because of a ghc bug, #624389. I've confirmed that the test case for that
bug doesn't reproduce it with ghc 7.4. So that's ok, except for the new ghc
bug I have not isolated and reported. Why does this simple bit of code
magnet the ghc bugs? :)
Also, the symlink touching code is currently broken, when used on utf-8
filenames in a non-utf-8 locale, or probably on any filename containing
undecodable bytes, and I temporarily commented it out.
2012-02-03 19:12:41 +00:00
|
|
|
calcMerge :: [(Ref, [String])] -> Either Ref [String]
|
2011-12-12 05:33:02 +00:00
|
|
|
calcMerge shacontents
|
|
|
|
| null reuseable = Right $ new
|
2011-12-15 22:11:42 +00:00
|
|
|
| otherwise = Left $ fst $ Prelude.head reuseable
|
2011-12-12 05:33:02 +00:00
|
|
|
where
|
|
|
|
reuseable = filter (\c -> sorteduniq (snd c) == new) shacontents
|
|
|
|
new = sorteduniq $ concat $ map snd shacontents
|
|
|
|
sorteduniq = S.toList . S.fromList
|