aboutsummaryrefslogtreecommitdiff
path: root/git-union-merge.hs
Commit message (Collapse)AuthorAge
* factor out nukeFileGravatar Joey Hess2012-06-06
|
* Add support for core.worktree, and fix support for GIT_WORK_TREE and GIT_DIR.Gravatar Joey Hess2012-05-18
| | | | | | | The environment needs to override git-config. Changed when git config is read, and avoid rereading it once it's been read. chdir for both worktree settings.
* Clean up handling of git directory and git worktree.Gravatar Joey Hess2012-05-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* git-annex, git-union-merge: Support GIT_DIR and GIT_WORK_TREE.Gravatar Joey Hess2012-01-13
| | | | | Note that GIT_WORK_TREE cannot influence GIT_DIR; that is necessary for git-fake-bare and vcsh type things to work.
* tweaksGravatar Joey Hess2012-01-11
|
* split more stuff out of Git.hsGravatar Joey Hess2011-12-14
|
* split out two more Git modulesGravatar Joey Hess2011-12-13
|
* split out three modules from GitGravatar Joey Hess2011-12-13
| | | | | Constructors and configuration make sense in separate modules. A separate Git.Types is needed to avoid cycles.
* optimize index updatingGravatar Joey Hess2011-12-11
| | | | | | | | | | | The last branch ref that the index was updated to is stored in .git/annex/index.lck, and the index only updated when the current branch ref differs. (The .lck file should later be used for locking too.) Some more optimization is still needed, since there is some redundancy in calls to git show-ref.
* improve type signatures with a Ref newtypeGravatar Joey Hess2011-11-16
| | | | | | | | | | | 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.
* reorder repo parameters lastGravatar Joey Hess2011-11-08
| | | | | | | | | | | | | Many functions took the repo as their first parameter. Changing it consistently to be the last parameter allows doing some useful things with currying, that reduce boilerplate. In particular, g <- gitRepo is almost never needed now, instead use inRepo to run an IO action in the repo, and fromRepo to get a value from the repo. This also provides more opportunities to use monadic and applicative combinators.
* faster union merge of multiple branches into indexGravatar Joey Hess2011-10-07
| | | | only write index once
* factor out common importsGravatar Joey Hess2011-10-03
| | | | no code changes
* go go gadget hlintGravatar Joey Hess2011-09-20
|
* make gitDir absoluteGravatar Joey Hess2011-08-19
|
* hlint tweaksGravatar Joey Hess2011-07-15
| | | | Did all sources except Remotes/* and Command/*
* rename GitUnionMerge to Git.UnionMergeGravatar Joey Hess2011-06-30
| | | | Also, moved commit function into Git proper, it's not union merge specific.
* renamed GitRepo to GitGravatar Joey Hess2011-06-30
| | | | It was always imported qualified as Git anyway
* add journaling to speed up changes to the git-annex branchGravatar Joey Hess2011-06-23
| | | | | | | | git is slow when the index file is large and has to be rewritten each time a file is changed. To speed this up, added a journal where changes are recorded before being fed into the index file and committed to the git-annex branch. The entire journal can be fed into git with just 2 commands, and only one write of the index file.
* allow for union merges between a tree and the content in the indexGravatar Joey Hess2011-06-21
| | | | | | | | | | | | | | | This is needed for robust handling of the git-annex branch. Since changes are staged to its index as git-annex runs, and committed at the end, it's possible that git-annex is interrupted, and leaves a dirty index. When it next runs, it needs to be able to merge the git-annex branch as necessary, without losing the existing changes in the index. Note that this assumes that the git-annex branch is only modified by git-annex. Any changes to it will be lost when git-annex updates the branch. I don't see a good, inexpensive way to find changes in the git-annex branch that arn't in the index, and union merging the git-annex branch into the index every time would likewise be expensive.
* export the commit function and generalizeGravatar Joey Hess2011-06-21
|
* Branch module completeGravatar Joey Hess2011-06-21
| | | | Refactored some code that it needs into GitRepo.
* refactorGravatar Joey Hess2011-06-21
|
* moved to libraryGravatar Joey Hess2011-06-21
|
* typoGravatar Joey Hess2011-06-20
|
* reorder git-union-merge paramsGravatar Joey Hess2011-06-20
|
* allow git-union-merge to write to any refGravatar Joey Hess2011-06-20
| | | | Not just refs/heads/* branches.
* sped up git-union-mergeGravatar Joey Hess2011-06-20
| | | | | | | | Avoided the slow git add, instead inject content directly into git and populate the index all in one pass. Now this runs on my large real-world repo in 10 seconds, which is acceptable. Also lots of code cleanups.
* add git-union-mergeGravatar Joey Hess2011-06-20
This is a new git subcommand, that does a generic union merge operation between two refs, storing the result in a branch. It operates efficiently without touching the working tree. It does need to write out a temporary index file, and may need to write out some other temp files as well. This could be useful for anything that stores data in a branch, and needs to merge changes into that branch without actually checking the branch out. Since conflict handling can't be done without a working copy, the merge type is always a union merge, which is fine for data stored in log format (as git-annex does), or in non-conflicting files (as pristine-tar does). This probably belongs in git proper, but it will live in git-annex for now. --- Plan is to move .git-annex/ to a git-annex branch, and use git-union-merge to handle merging changes when pulling from remotes. Some preliminary benchmarking using real .git-annex/ data indicates that it's quite fast, except for the "git add" call, which is as slow as "git add" tends to be with a big index.