2011-12-13 19:05:07 +00:00
|
|
|
{- git repository configuration handling
|
|
|
|
-
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
- Copyright 2010-2012 Joey Hess <joey@kitenet.net>
|
2011-12-13 19:05:07 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
2011-12-15 20:04:08 +00:00
|
|
|
module Git.Config where
|
2011-12-13 19:05:07 +00:00
|
|
|
|
|
|
|
import qualified Data.Map as M
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
import Data.Char
|
2011-12-13 19:05:07 +00:00
|
|
|
|
|
|
|
import Common
|
|
|
|
import Git
|
|
|
|
import Git.Types
|
|
|
|
import qualified Git.Construct
|
|
|
|
|
|
|
|
{- Returns a single git config setting, or a default value if not set. -}
|
|
|
|
get :: String -> String -> Repo -> String
|
|
|
|
get key defaultValue repo = M.findWithDefault defaultValue key (config repo)
|
|
|
|
|
2012-04-22 05:13:09 +00:00
|
|
|
{- Returns a list with each line of a multiline config setting. -}
|
|
|
|
getList :: String -> Repo -> [String]
|
|
|
|
getList key repo = M.findWithDefault [] key (fullconfig repo)
|
|
|
|
|
2012-01-10 03:31:44 +00:00
|
|
|
{- Returns a single git config setting, if set. -}
|
|
|
|
getMaybe :: String -> Repo -> Maybe String
|
|
|
|
getMaybe key repo = M.lookup key (config repo)
|
|
|
|
|
2012-05-18 22:20:53 +00:00
|
|
|
{- Runs git config and populates a repo with its config.
|
2012-05-19 14:22:43 +00:00
|
|
|
- Avoids re-reading config when run repeatedly. -}
|
|
|
|
read :: Repo -> IO Repo
|
|
|
|
read repo@(Repo { config = c })
|
|
|
|
| c == M.empty = read' repo
|
|
|
|
| otherwise = return repo
|
|
|
|
|
|
|
|
{- Reads config even if it was read before. -}
|
|
|
|
reRead :: Repo -> IO Repo
|
|
|
|
reRead = read'
|
|
|
|
|
|
|
|
{- Cannot use pipeRead because it relies on the config having been already
|
2012-05-18 22:20:53 +00:00
|
|
|
- read. Instead, chdir to the repo.
|
|
|
|
-}
|
2012-05-19 14:22:43 +00:00
|
|
|
read' :: Repo -> IO Repo
|
|
|
|
read' repo = go repo
|
|
|
|
where
|
|
|
|
go Repo { location = Local { gitdir = d } } = git_config d
|
|
|
|
go Repo { location = LocalUnknown d } = git_config d
|
|
|
|
go _ = assertLocal repo $ error "internal"
|
|
|
|
git_config d = bracketCd d $
|
|
|
|
pOpen ReadFromPipe "git" ["config", "--null", "--list"] $
|
|
|
|
hRead repo
|
2011-12-13 19:05:07 +00:00
|
|
|
|
|
|
|
{- Reads git config from a handle and populates a repo with it. -}
|
|
|
|
hRead :: Repo -> Handle -> IO Repo
|
|
|
|
hRead repo h = do
|
|
|
|
val <- hGetContentsStrict h
|
|
|
|
store val repo
|
|
|
|
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
{- Stores a git config into a Repo, returning the new version of the Repo.
|
|
|
|
- The git config may be multiple lines, or a single line.
|
|
|
|
- Config settings can be updated incrementally.
|
|
|
|
-}
|
2011-12-13 19:05:07 +00:00
|
|
|
store :: String -> Repo -> IO Repo
|
|
|
|
store s repo = do
|
2011-12-30 18:07:17 +00:00
|
|
|
let c = parse s
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
let repo' = updateLocation $ repo
|
2011-12-30 18:07:17 +00:00
|
|
|
{ config = (M.map Prelude.head c) `M.union` config repo
|
|
|
|
, fullconfig = M.unionWith (++) c (fullconfig repo)
|
|
|
|
}
|
2011-12-13 19:05:07 +00:00
|
|
|
rs <- Git.Construct.fromRemotes repo'
|
|
|
|
return $ repo' { remotes = rs }
|
|
|
|
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
{- Updates the location of a repo, based on its configuration.
|
|
|
|
-
|
|
|
|
- Git.Construct makes LocalUknown repos, of which only a directory is
|
|
|
|
- known. Once the config is read, this can be fixed up to a Local repo,
|
|
|
|
- based on the core.bare and core.worktree settings.
|
|
|
|
-}
|
|
|
|
updateLocation :: Repo -> Repo
|
2012-05-19 14:51:22 +00:00
|
|
|
updateLocation r@(Repo { location = LocalUnknown d })
|
|
|
|
| isBare r = newloc $ Local d Nothing
|
|
|
|
| otherwise = newloc $ Local (d </> ".git") (Just d)
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
where
|
2012-05-19 14:51:22 +00:00
|
|
|
newloc l = r { location = getworktree l }
|
|
|
|
getworktree l = case workTree r of
|
|
|
|
Nothing -> l
|
|
|
|
wt -> l { worktree = wt }
|
|
|
|
updateLocation r = r
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
|
2011-12-15 16:46:04 +00:00
|
|
|
{- Parses git config --list or git config --null --list output into a
|
|
|
|
- config map. -}
|
2011-12-30 18:07:17 +00:00
|
|
|
parse :: String -> M.Map String [String]
|
2011-12-15 16:46:04 +00:00
|
|
|
parse [] = M.empty
|
|
|
|
parse s
|
|
|
|
-- --list output will have an = in the first line
|
2011-12-15 20:04:08 +00:00
|
|
|
| all ('=' `elem`) (take 1 ls) = sep '=' ls
|
2011-12-15 16:46:04 +00:00
|
|
|
-- --null --list output separates keys from values with newlines
|
2011-12-15 17:05:47 +00:00
|
|
|
| otherwise = sep '\n' $ split "\0" s
|
2011-12-13 19:05:07 +00:00
|
|
|
where
|
2011-12-15 16:46:04 +00:00
|
|
|
ls = lines s
|
2011-12-30 18:07:17 +00:00
|
|
|
sep c = M.fromListWith (++) . map (\(k,v) -> (k, [v])) .
|
|
|
|
map (separate (== c))
|
Clean up handling of git directory and git worktree.
Baked into the code was an assumption that a repository's git directory
could be determined by adding ".git" to its work tree (or nothing for bare
repos). That fails when core.worktree, or GIT_DIR and GIT_WORK_TREE are
used to separate the two.
This was attacked at the type level, by storing the gitdir and worktree
separately, so Nothing for the worktree means a bare repo.
A complication arose because we don't learn where a repository is bare
until its configuration is read. So another Location type handles
repositories that have not had their config read yet. I am not entirely
happy with this being a Location type, rather than representing them
entirely separate from the Git type. The new code is not worse than the
old, but better types could enforce more safety.
Added support for core.worktree. Overriding it with -c isn't supported
because it's not really clear what to do if a git repo's config is read, is
not bare, and is then overridden to bare. What is the right git directory
in this case? I will worry about this if/when someone has a use case for
overriding core.worktree with -c. (See Git.Config.updateLocation)
Also removed and renamed some functions like gitDir and workTree that
misused git's terminology.
One minor regression is known: git annex add in a bare repository does not
print a nice error message, but runs git ls-files in a way that fails
earlier with a less nice error message. This is because before --work-tree
was always passed to git commands, even in a bare repo, while now it's not.
2012-05-18 20:38:26 +00:00
|
|
|
|
|
|
|
{- Checks if a string from git config is a true value. -}
|
|
|
|
isTrue :: String -> Maybe Bool
|
|
|
|
isTrue s
|
|
|
|
| s' == "true" = Just True
|
|
|
|
| s' == "false" = Just False
|
|
|
|
| otherwise = Nothing
|
|
|
|
where
|
|
|
|
s' = map toLower s
|
2012-05-19 14:51:22 +00:00
|
|
|
|
|
|
|
isBare :: Repo -> Bool
|
|
|
|
isBare r = fromMaybe False $ isTrue =<< getMaybe "core.bare" r
|
|
|
|
|
|
|
|
workTree :: Repo -> Maybe FilePath
|
|
|
|
workTree = getMaybe "core.worktree"
|