aboutsummaryrefslogtreecommitdiff
path: root/Git/LsFiles.hs
Commit message (Collapse)AuthorAge
* remove Params constructor from Utility.SafeCommandGravatar Joey Hess2015-06-01
| | | | | | | | | | | | | | | | | | This removes a bit of complexity, and should make things faster (avoids tokenizing Params string), and probably involve less garbage collection. In a few places, it was useful to use Params to avoid needing a list, but that is easily avoided. Problems noticed while doing this conversion: * Some uses of Params "oneword" which was entirely unnecessary overhead. * A few places that built up a list of parameters with ++ and then used Params to split it! Test suite passes.
* removed all uses of undefined from code baseGravatar Joey Hess2015-04-19
| | | | It's a code smell, can lead to hard to diagnose error messages.
* use --literal-pathspecs globally, as a better way to avoid globbingGravatar Joey Hess2015-03-30
| | | | | | | | This might be overkill; I only know I need it in ls-files, but other git commands can also do their own globbing, it turns out, and I am pretty sure I never want them too when git-annex is using them as plumbing. Test suite still passes and it looks ok.
* workaround git ls-files bug in handling slash-escaped wildcardsGravatar Joey Hess2015-03-30
| | | | | | | | | | | There's no good solution for git-annex here; I can't escape or un-escape and avoid breaking in some cases, so I've chosen the combo least likely to result in breakage. Git really needs to fix its behavior here. The only other thing git-annex could do is treat this as a feature, and don't try to escape at all. Ugh.
* Prevent git-ls-files from double-expanding wildcards when an unexpanded ↵Gravatar Joey Hess2015-03-27
| | | | | | | | | | wildcard is passed to a git-annex command like add or find. Note that previously, `git annex find *.jpg` would find eg, foo/bar.jpg. That was never intended or documented behavior, so I'm going to change it. But this is potentially a behavior change if someone discovered that behavior and relied on it despite it being accidental. Oh well.. can't make an omlette w/o breaking some eggs.
* promote forum request to todo item so it is not lostGravatar Joey Hess2015-03-27
|
* update my email address and homepage urlGravatar Joey Hess2015-01-21
|
* Switch to using relative paths to the git repository.Gravatar Joey Hess2015-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | This allows the git repository to be moved while git-annex is running in it, with fewer problems. On Windows, this avoids some of the problems with the absurdly small MAX_PATH of 260 bytes. In particular, git-annex repositories should work in deeper/longer directory structures than before. See http://git-annex.branchable.com/bugs/__34__git-annex:_direct:_1_failed__34___on_Windows/ There are several possible ways this change could break git-annex: 1. If it changes its working directory while it's running, that would be Bad News. Good news everyone! git-annex never does so. It would also break thread safety, so all such things were stomped out long ago. 2. parentDir "." -> "" which is not a valid path. I had to fix one instace of this, and I should probably wipe all calls to parentDir out of the git-annex code base; it was never a good idea. 3. Things like relPathDirToFile require absolute input paths, and code assumes that the git repo path is absolute and passes it to it as-is. In the case of relPathDirToFile, I converted it to not make this assumption. Currently, the test suite has 16 failures.
* export CreateProcess fields from Utility.ProcessGravatar Joey Hess2014-06-10
| | | | update code to avoid cwd and env redefinition warnings
* status: Ignore new files that are gitignored.Gravatar Joey Hess2013-12-12
|
* add new status commandGravatar Joey Hess2013-11-07
| | | | | | | | | | | | | | | This works for both direct and indirect mode. It may need some performance tuning. Note that unlike git status, it only shows the status of the work tree, not the status of the index. So only one status letter, not two .. and since files that have been added and not yet committed do not differ between the work tree and the index, they are not shown. Might want to add display of the index vs the last commit eventually. This commit was sponsored by an unknown bitcoin contributor, whose contribution as been going up lately! ;)
* repair command: add handling of git-annex branch and indexGravatar Joey Hess2013-10-23
|
* remove *>=> and >=*> ; use <$$> insteadGravatar Joey Hess2013-09-27
| | | | | | | | I forgot I had <$$> hidden away in Utility.Applicative. It allows doing the same kind of currying as does >=*> and I found using it made the code more readable for me. (*>=> was not used)
* sync, pre-commit, indirect: Avoid unnecessarily catting non-symlink files ↵Gravatar Joey Hess2013-09-19
| | | | from git, which can be so large it runs out of memory.
* unused: Pay attention to symlinks that are not yet staged in the index.Gravatar Joey Hess2013-08-22
|
* importfeed: git-annex becomes a podcatcher in 150 LOCGravatar Joey Hess2013-07-28
|
* fix the day's windows permissions damageGravatar Joey Hess2013-05-12
|
* set raw mode for git check-attrGravatar Joey Hess2013-05-12
|
* Bugfix: git annex add, when ran without any file or directory specified, ↵Gravatar Joey Hess2013-03-07
| | | | should add files in the current directory, but not act on unlocked files elsewhere in the tree.
* make adding modified files work on crippled filesystemsGravatar Joey Hess2013-02-20
|
* 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