mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

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

Browse source
This commit is contained in:
Joey Hess 2014-09-12 13:55:24 -04:00
commit 3735e64c61
5 changed files with 146 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_2_9b74457549e2739ae45dccd128de946f._comment Normal file
View file

@ -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..
"""]]

12
doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_3_5790bbbe347e1806062ccb60fcad046a._comment Normal file
View file

@ -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.
"""]]

12
doc/bugs/Bloom_filter_capacity_too_large_to_represent/comment_4_9fb9fdbc6218d6b86b0921f411f78891._comment Normal file
View file

@ -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.
"""]]

97
doc/forum/Move_unsynced_file_in_direct_mode.mdwn Normal file
View file

@ -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?

13
doc/forum/usability:_creating_an_archive_on_a_new_external_drive.mdwn Normal file
View file

@ -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]]