Merge branch 'master' of ssh://git-annex.branchable.com

5 files changed, 146 insertions, 0 deletions

diff --git a/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_2_9b74457549e2739ae45dccd128de946f._comment b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_2_9b74457549e2739ae45dccd128de946f._comment
new file mode 100644
index 000000000..803465e01
--- /dev/null
+++ b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_2_9b74457549e2739ae45dccd128de946f._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.132"
+ subject="comment 2"
+ date="2014-09-12T16:34:56Z"
+ content="""
+However, in Greg's case he had no such configuration. Instead, I think something is broken with the use of floating point or bit math that bloomfilter uses, on the NAS where he's using git-annex.
+
+I have made git-annex not crash when this happens, just show a warning and fall back to a reasonable default bloom filter size. If the problem is with the bit math, then the bloom filter may not work either, which would probably show up as false negatives, so `git annex unused` not finding things that are unused. 
+
+I need to update the armel build with this so Greg can test it..
+"""]]
diff --git a/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_3_5790bbbe347e1806062ccb60fcad046a._comment b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_3_5790bbbe347e1806062ccb60fcad046a._comment
new file mode 100644
index 000000000..a11d0efc7
--- /dev/null
+++ b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_3_5790bbbe347e1806062ccb60fcad046a._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.132"
+ subject="comment 3"
+ date="2014-09-12T16:38:47Z"
+ content="""
+I have reproduced the bug, using the standalone build on an arm box (turtle). 
+
+On the same box, the debian git-annex build works ok.
+
+Suggests to me the problem is related to the cross-compiling method used for the standalone arm build.
+"""]]
diff --git a/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_4_9fb9fdbc6218d6b86b0921f411f78891._comment b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_4_9fb9fdbc6218d6b86b0921f411f78891._comment
new file mode 100644
index 000000000..77097e07c
--- /dev/null
+++ b/doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_4_9fb9fdbc6218d6b86b0921f411f78891._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="209.250.56.132"
+ subject="turns out to be an upstream bug already filed"
+ date="2014-09-12T17:46:23Z"
+ content="""
+It seems that this is a bug on bloomfilter 2.0.0.0 on armel generally. It's also preventing this newer version from building on armel currently:
+
+<http://bugs.debian.org/756801>
+
+The git-annex standalone arm autobuilder installed it with cabal, so ended up with the newer, broken version. 
+"""]]
diff --git a/doc/forum/Move_unsynced_file_in_direct_mode.mdwn b/doc/forum/Move_unsynced_file_in_direct_mode.mdwn
new file mode 100644
index 000000000..015b5f58e
--- /dev/null
+++ b/doc/forum/Move_unsynced_file_in_direct_mode.mdwn
@@ -0,0 +1,97 @@
+When I rename unsynced files in a direct mode repo, the original symlink gets removed from git, but the new symlink doesn't get added back by autocommit or by explicitly using `git annex add`.
+
+First, I create a file in a git-annex repo:
+
+        $ mkdir annex1
+        $ cd annex1
+        $ git init
+        Initialized empty Git repository in /home/cwarden/annex1/.git/
+        $ git annex init
+        init  ok
+        (Recording state in git...)
+        $ echo test > test1
+        $ git annex add test1
+        add test1 ok
+        (Recording state in git...)
+        $ git annex sync
+        commit  ok
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test1 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ cat test1
+        test
+
+Now, I clone the repo and enable autocommit and direct mode in the second repo:
+
+        $ cd ..
+        $ git clone annex1 annex2
+        Cloning into 'annex2'...
+        done.
+        $ cd annex2
+        $ git config annex.autocommit true
+        $ git annex direct
+        commit
+        On branch master
+        Your branch is up-to-date with 'origin/master'.
+
+        nothing to commit, working directory clean
+        ok
+        direct  ok
+
+I drop the file, then rename it:
+
+        $ git annex drop test1
+        (merging origin/git-annex into git-annex...)
+        (Recording state in git...)
+        $ mv test1 test2
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test2 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ git annex sync
+        commit  (Recording state in git...)
+        ok
+        pull origin
+        ok
+        push origin
+        Counting objects: 6, done.
+        Delta compression using up to 4 threads.
+        Compressing objects: 100% (5/5), done.
+        Writing objects: 100% (6/6), 674 bytes | 0 bytes/s, done.
+        Total 6 (delta 1), reused 0 (delta 0)
+        To /home/cwarden/annex1
+                2772756..ffcb7a1  annex/direct/master -> synced/master
+         * [new branch]      git-annex -> synced/git-annex
+        ok
+        (Recording state in git...)
+
+Now, I want to get the renamed file:
+
+        $ git annex get test2
+        $ ls -l
+        total 4
+        lrwxrwxrwx 1 cwarden cwarden 178 Sep 12 10:14 test2 -> .git/annex/objects/w8/pv/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2/SHA256E-s5--f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2
+        $ cat test2
+        cat: test2: No such file or directory
+
+Explicitly adding test2 doesn't work:
+
+        $ git annex add test2
+        $ git annex get test2
+        $ cat test2
+        cat: test2: No such file or directory
+
+`git annex fsck` doesn't help:
+
+        $ git annex fsck
+        $ cat test2
+        cat: test2: No such file or directory
+
+The only way I've found to get the renamed file back into git is to use `core.bare=false`, but the [documentation](http://git-annex.branchable.com/direct_mode/) says that "there should be no good reason to need to do this, ever".
+
+        $ git -c core.bare=false add test2
+        $ git -c core.bare=false commit -m'force renamed file back into git'
+        $ git annex get test2
+        $ cat test2
+        test
+
+Is there a better solution?
diff --git a/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
new file mode 100644
index 000000000..a6bc0b7bd
--- /dev/null
+++ b/doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn
@@ -0,0 +1,13 @@
+story: i got a new drive from the store. plug it in. it's recognized by XFCE and mounted automatically. turns out it's NTFS, but Debian doesn't seem to mind.
+
+go in the assistant, add it as an "External drive", make it a "full backup" and let it sync.
+
+expected result: i see files
+
+actual result: i see a bare git repository.
+
+if i first `git init` the directory so it's not bare, at least i get a better handle on it: i can sync with the assistant, then `git merge synced/master` to see the files.
+
+really confusing to me, sorry if it's a dupe... 
+
+workaround: use the commandline: `git clone <repo>` and `git annex get`. --[[anarcat]]