summaryrefslogtreecommitdiff
path: root/Git/LsFiles.hs
Commit message (Collapse)AuthorAge
* make startup scan for deleted files work in direct modeGravatar Joey Hess2012-12-24
| | | | | | | | | | git add --update cannot be used, because it'll stage typechanged direct mode files. Intead, use ls-files to find deleted files, and stage them ourselves. It seems that no commit was made before when the scan staged deleted files. (Probably masked since if files were added, a commit happened then..) Now that I'm doing the staging, I was also able to fix that bug.
* unusedGravatar Joey Hess2012-12-18
|
* Merge branch 'master' into desymlinkGravatar Joey Hess2012-12-13
|\ | | | | | | | | | | | | | | Conflicts: Annex/CatFile.hs Annex/Content.hs Git/LsFiles.hs Git/LsTree.hs
| * finished where indentation changesGravatar Joey Hess2012-12-13
| |
* | direct mode committingGravatar Joey Hess2012-12-12
| |
* | add notStagedGravatar Joey Hess2012-12-12
| |
* | where indentationGravatar Joey Hess2012-12-12
| |
* | remove unused functionGravatar Joey Hess2012-12-12
|/
* remove some more !!Gravatar Joey Hess2012-10-20
|
* fix last zombies in the assistantGravatar Joey Hess2012-10-04
| | | | | Made Git.LsFiles return cleanup actions, and everything waits on processes now, except of course for Seek.
* more zombie fightingGravatar Joey Hess2012-10-04
| | | | | | | | | | | | | | | | | | | | I'm down to 9 places in the code that can produce unwaited for zombies. Most of these are pretty innocuous, at least for now, are only used in short-running commands, or commands that run a set of actions and explicitly reap zombies after each one. The one from Annex.Branch.files could be trouble later, since both Command.Fsck and Command.Unused can trigger it, and the assistant will be doing those eventally. Ditto the one in Git.LsTree.lsTree, which Command.Unused uses. The only ones currently affecting the assistant though, are in Git.LsFiles. Several threads use several of those. (And yeah, using pipes or ResourceT would be a less ad-hoc approach, but I don't really feel like ripping my entire code base apart right now to change a foundation monad. Maybe one of these days..)
* sync: Automatically resolves merge conflicts.Gravatar Joey Hess2012-06-27
| | | | untested, but it compiles :)
* properly handle deleted files when processing ls-files --unmergedGravatar Joey Hess2012-06-27
|
* add ls-files --unmerged supportGravatar Joey Hess2012-06-27
|
* 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.
* fix LsFiles.typeChanged pathsGravatar Joey Hess2012-02-14
| | | | | | Passing absolute paths to Command.Add used to work, but after recent changes doesn't. All LsFiles should use relative paths anyway, so fix it there.
* use Common in a few more modulesGravatar Joey Hess2011-12-20
|
* split out Git/Command.hsGravatar Joey Hess2011-12-14
|
* lintGravatar Joey Hess2011-11-11
|
* 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.
* convert all git read/write functions to use ByteStringsGravatar Joey Hess2011-09-29
| | | | | | | | | | This yields a second or so speedup in unused, find, etc. Seems that even when the ByteString is immediately split and then converted to Strings, it's faster. I may try to push ByteStrings out into more of git-annex gradually, although I suspect most of the time-critical parts are already covered now, and many of the rest rely on libraries that only support Strings.
* tweakGravatar Joey Hess2011-09-25
|
* split groups of related functions out of UtilityGravatar Joey Hess2011-08-22
|
* hlint tweaksGravatar Joey Hess2011-07-15
| | | | Did all sources except Remotes/* and Command/*
* renamed GitRepo to GitGravatar Joey Hess2011-06-30
It was always imported qualified as Git anyway