diff options
author | Joey Hess <joey@kitenet.net> | 2014-09-12 13:55:24 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2014-09-12 13:55:24 -0400 |
commit | 7114cf3d31a8e5bbe7044370a2db6e63c3e18e50 (patch) | |
tree | 92985321451065305d06c0fcbac2d96e7cf27ad9 /doc | |
parent | 3a326afceb91e818b228c213d50593f0e50c6112 (diff) | |
parent | d71d8ee54b29498a62f90b56b00e3478da723244 (diff) |
Merge branch 'master' of ssh://git-annex.branchable.com
Diffstat (limited to 'doc')
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]] |