summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* support all filename encodings with ghc 7.4Gravatar Joey Hess2012-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* add a check for not utf-8 consoleGravatar Joey Hess2012-02-03
|
* attempt at a quick, utf-8 only fix to the ghc 7.4 problemGravatar Joey Hess2012-02-01
| | | | | If you have only utf-8 filenames, and need to build git-annex with ghc 7.4, this will work. But, it will crash on non-utf-8 filenames.
* add a test case for adding a file with a unicode filenameGravatar Joey Hess2012-01-31
| | | | This fails with ghc 4.7.
* Merge branch 'master' of ssh://git-annex.branchable.comGravatar Joey Hess2012-01-30
|\
* | remove; unusedGravatar Joey Hess2012-01-30
| |
* | switch to the strict state monadGravatar Joey Hess2012-01-29
| | | | | | | | | | | | | | | | | | | | I had not realized what a memory leak the lazy state monad could be, although I have not seen much evidence of actual leaking in git-annex. However, if running git-annex on a great many files, this could matter. The additional Utility.State.changeState adds even more strictness, avoiding a problem I saw in github-backup where repeatedly modifying state built up a huge pile of thunks.
| * Added a commentGravatar https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX42012-01-29
|/
* reopenGravatar Joey Hess2012-01-28
| | | | | People seem to want to post comments here with vague details about a new bug, rather than opening a new bug report.
* fixedGravatar Joey Hess2012-01-28
|
* Merge branch 'master' of ssh://git-annex.branchable.comGravatar Joey Hess2012-01-28
|\
* | faster local-local droppingGravatar Joey Hess2012-01-28
| | | | | | | | | | | | Dropping a key from a local remote ran git-annex-shell unnecessarily. Now git-annex-shell is never used when acting on a local remote.
* | Avoid repeated location log commits when a remote is receiving files.Gravatar Joey Hess2012-01-28
| | | | | | | | | | | | | | | | | | Done by adding a oneshot mode, in which location log changes are written to the journal, but not committed. Taking advantage of git-annex's existing ability to recover in this situation. This is used by git-annex-shell and other places where changes are made to a remote's location log.
| * Added a commentGravatar http://joey.kitenet.net/2012-01-28
| |
| * Added a commentGravatar http://joey.kitenet.net/2012-01-28
| |
* | Revert "Avoid creating ~/.bup when initializing a bup remote"Gravatar Joey Hess2012-01-28
|/ | | | | | | | | | | | | | This reverts commit 6da40100c99a097401fb130b63edc05b18f61249. On closer examinaton, this change is wrong. The bup special remote can be configured with "buprepo=", which makes it use the default ~/.bup repo. This change makes it use a different temp dir each time, which I'm sure would not be appreciated by anyone with that configuration. Bup insisting in creating ~/.bup even when using a different repo does seem like a bug in *something*, but I'm leaning toward the bug being in bup itself.
* Added a commentGravatar https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX42012-01-28
|
* Added a commentGravatar https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX42012-01-28
|
* Added a commentGravatar http://joey.kitenet.net/2012-01-27
|
* old version?Gravatar Joey Hess2012-01-27
|
* Merge branch 'master' of ssh://git-annex.branchable.comGravatar Joey Hess2012-01-27
|\
| * (no commit message)Gravatar https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX42012-01-27
| |
| * Added a commentGravatar https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX42012-01-26
| |
| * Avoid creating ~/.bup when initializing a bup remoteGravatar Lauri Alanko2012-01-26
| |
* | fix error messageGravatar Joey Hess2012-01-25
| |
* | export fromPathGravatar Joey Hess2012-01-25
|/ | | | Not used in git-annex, but I am using it in git-backup
* addGravatar Joey Hess2012-01-25
|
* closeGravatar Joey Hess2012-01-24
|
* remove Utility.Conditional and use IfElseGravatar Joey Hess2012-01-24
| | | | | | | This drops the >>! and >>? with the nice low fixity. IfElse does have undocumented >>=>>! and >>=>>? operators, but I deem that too fishy. Anyway, using whenM and unlessM is easier; I sometimes mixed the operators up.
* rename readMaybe to readishGravatar Joey Hess2012-01-23
| | | | a stricter (but also partial) readMaybe is getting added to base
* a few things available elsewhere...Gravatar Joey Hess2012-01-23
|
* add news item for git-annex 3.20120123Gravatar Joey Hess2012-01-23
|
* releasing version 3.201201233.20120123Gravatar Joey Hess2012-01-23
|
* Added a commentGravatar http://joey.kitenet.net/2012-01-23
|
* (no commit message)Gravatar https://www.google.com/accounts/o8/id?id=AItOawlB7-aXsqwzOi2BIR_Q4sUF8sjj24H6F3c2012-01-23
|
* treakGravatar Joey Hess2012-01-21
|
* order user provided params after connection caching paramsGravatar Joey Hess2012-01-20
| | | | So the user can override them.
* add annex.sshcaching config settingGravatar Joey Hess2012-01-20
|
* ssh connection cachingGravatar Joey Hess2012-01-20
| | | | | | | | | | | Ssh connection caching is now enabled automatically by git-annex. Only one ssh connection is made to each host per git-annex run, which can speed some things up a lot, as well as avoiding repeated password prompts. Concurrent git-annex processes also share ssh connections. Cached ssh connections are shut down when git-annex exits. Note: The rsync special remote does not yet participate in the ssh connection caching.
* typoGravatar Joey Hess2012-01-20
|
* fsck --from remote --fastGravatar Joey Hess2012-01-20
| | | | | | | Avoids expensive file transfers, at the expense of checking file size and/or contents. Required some reworking of the remote code.
* better designGravatar Joey Hess2012-01-19
| | | | | Avoids possible repeated password prompts, at the cost of a small bit of locking complication.
* designGravatar Joey Hess2012-01-19
|
* (no commit message)Gravatar https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck2012-01-19
|
* optimise fsck --from normal git remotesGravatar Joey Hess2012-01-19
| | | | | | | | | | For a local git remote, can symlink the file. For a git remote using rsync, can preseed any local content. There are a few reasons to use fsck --from on a normal git remote. One is if it's using gitosis or similar, and you don't have shell access to run git annex locally. Another reason could be if you just want to fsck certian files of a bare remote.
* use a different tmp file when fscking remote dataGravatar Joey Hess2012-01-19
| | | | | Since the content might be symlinked into place, it's not appropriate to use withTmp here.
* optimize fsck --from directory special remoteGravatar Joey Hess2012-01-19
| | | | No need to copy anything, just symlink to the file.
* add tmp flag parameter to retrieveKeyFileGravatar Joey Hess2012-01-19
|
* optimise fsck --from rsync special remoteGravatar Joey Hess2012-01-19
| | | | | When a file is present locally, the remote's version can be rsynced to a copy of it, which will avoid wasting a lot of bandwidth.
* update NEWSGravatar Joey Hess2012-01-19
| | | | | | | | | Add news item recommending fscking directory special remotes. Remote news item about URL backend being removed; it was later added back to be used by git annex addurl --fast. Link NEWS into top level.