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

3 files changed, 74 insertions, 0 deletions

diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn b/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn
new file mode 100644
index 000000000..68328ac96
--- /dev/null
+++ b/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn
@@ -0,0 +1,48 @@
+[[!format sh """
+greg@x200s:~/Documents$ git-annex unused
+unused . (checking for unused data...) (checking annex/direct/master...) (checking synced/annex/direct/master...) (checking synology/master...) 
+  Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s16367--0b00ef0154c42a0bf94e5be8d92d8af27455d59794f26c33dfc39c09178521c9.pdf
+    2       SHA256E-s84--b08e1c831863bb43c02158bd5e8f3f5416c3a5203d89fa94a22149460142c273.odt
+    3       SHA256E-s84--ec4caae451180a29721f2b6667eec8ec80eaa724f0727cf99d2bb21bf9218e9d.odt
+    ...
+    88      SHA256E-s84--710d69bef61674b04974ac550d713e5928563b2a12b902b64fe451705b967452.doc
+    89      SHA256E-s3830--1348d6248e35625da3e22f73d2a0017185bb5e1aa37f65bbca5dfcb3c7f53034
+    90      SHA256E-s119822--7c1b53ab6402b8835473f0b5c326f3cc300ac9372be79694942c1efa4bcdc621.pdf
+    91      SHA256E-s84--63b6188696795885ff6570a76a3a74799396787f7058cbcfd4a2c40b22982420.odt
+  (To see where data was previously used, try: git log --stat -S'KEY')
+  
+  To remove unwanted data: git-annex dropunused NUMBER
+  
+ok
+greg@x200s:~/Documents$ git-annex copy --unused --to synology
+"""]]
+
+Is that correct behavior? I would assume the last command would at least run through the 91 files and check my synology remote that they are there. Like this repo did:
+
+[[!format sh """
+$ git-annex unused
+unused . (checking for unused data...) (checking master...) (checking 60justin/master...)
+  Some annexed data is no longer used by any files:
+    NUMBER  KEY
+    1       SHA256E-s9390266--7ed16c9423b331dbe63bb3b4278b8c94a6754a07177c53fceb3b24e9610e8054.NEF
+    2       SHA256E-s10435713--49cbfe8466eada2c3787c9a7e158a7dfb9845a0aa8ef862ed2578b59c889dc4d.NEF
+    3       SHA256E-s9442044--85c314e318f643237df5e3adf7559e9bf268ee28f1f92d4102161865323ddeb6.NEF
+    4       SHA256E-s290672--c5822c3ef16bd62b5752b2dace81182ce00d64bd4d2d994ba93e3cb94e645708.JPG
+    5       SHA256E-s293288--30f1367fc326f7b053012818863151206f9e3ddeab3c3fc5b5c1c573d120d50a.JPG
+    6       SHA256E-s3672986--be960f6dc247df2496f634f7d788bd4a180fe556230e2dafc23ebc8fc1f10af3.JPG
+  (To see where data was previously used, try: git log --stat -S'KEY')
+
+  To remove unwanted data: git-annex dropunused NUMBER
+
+ok
+$ git-annex copy --unused --to synology
+copy SHA256E-s9390266--7ed16c9423b331dbe63bb3b4278b8c94a6754a07177c53fceb3b24e9610e8054.NEF (checking synology...) ok
+copy SHA256E-s10435713--49cbfe8466eada2c3787c9a7e158a7dfb9845a0aa8ef862ed2578b59c889dc4d.NEF (checking synology...) ok
+copy SHA256E-s9442044--85c314e318f643237df5e3adf7559e9bf268ee28f1f92d4102161865323ddeb6.NEF (checking synology...) ok
+copy SHA256E-s290672--c5822c3ef16bd62b5752b2dace81182ce00d64bd4d2d994ba93e3cb94e645708.JPG (checking synology...) ok
+copy SHA256E-s293288--30f1367fc326f7b053012818863151206f9e3ddeab3c3fc5b5c1c573d120d50a.JPG (checking synology...) ok
+copy SHA256E-s3672986--be960f6dc247df2496f634f7d788bd4a180fe556230e2dafc23ebc8fc1f10af3.JPG (checking synology...) ok
+$
+"""]]
diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment
new file mode 100644
index 000000000..cedc0f7f9
--- /dev/null
+++ b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://grossmeier.net/"
+ nickname="greg"
+ subject="indirect vs direct"
+ date="2014-02-20T06:25:31Z"
+ content="""
+Aha! The issue is that the first repo (the one not copying unused files to synology) was in direct mode. I switched it to indirect and not only are there now a lot more files listed in unused, but copy --unused is working as expected.
+
+Should there be a warning in git-annex unused when in direct mode about this? I'm not exactly sure what is happening (not sure why the number of unused would go up from 91 to 296).
+"""]]
diff --git a/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn b/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn
new file mode 100644
index 000000000..076f3ce4a
--- /dev/null
+++ b/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn
@@ -0,0 +1,16 @@
+This is just an idea, and I have no idea if it would work (that's why I'm asking):
+
+**Would it be possible to use ASICs made for Bitcoin mining inside git-annex to offload the hashing of files?**
+
+I got the idea, because I have two RaspberryPis here: 
+
+- one runs my git-annex archive. It is really slow at hashing, so I resorted to using the WORM backend
+- another one runs 2 old-ish ASIC miners. They are just barely "profitable" right now, so in a few months they will be obsolete
+
+Both devices to some kind of `SHA256`. I have a feeling this is either extremely easy or extremely complicated to do… :)
+
+> git-annex uses binaries such as `sha256sum` for hashing large files (large is
+> currently hardcoded as bigger than 1MB). If you insert a binary with the same
+> interface as `sha256sum` into your `$PATH`, git-annex will automatically use
+> it. If you want to use ASIC hashing even for small files, you need to tweak
+> `Backend/Hash.hs`. --[[HelmutGrohne]]