summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2013-03-06 16:36:31 -0400
committerGravatar Joey Hess <joey@kitenet.net>2013-03-06 16:36:31 -0400
commitfc2b69ef5704f819ff14b5161d6d246724de333b (patch)
treecef116d3624225ff421884c33d672834d700e0fd
parent446f996fee22eec7fdf37ca14bbdc724afae56d0 (diff)
parentf983e9072236190e982d7141cc80fae145d2c084 (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/bugs/encryption_key_is_surprising/comment_5_cd7cbf0c0ee9cafec344dfbf1acd9590._comment8
-rw-r--r--doc/bugs/encryption_key_is_surprising/comment_6_01381524114d885961704acc3f172536._comment8
-rw-r--r--doc/bugs/git-annex_dropunused_has_no_effect/comment_4_f05a9a3760858c5ee5c98dd8ab059c28._comment8
-rw-r--r--doc/bugs/three_way_sync_via_S3_and_Jabber/comment_10_fc5ec5505f141bb9135e772d1094bc4d._comment10
-rw-r--r--doc/forum/Difference_between_copy__44___move_and_get__63__.mdwn24
5 files changed, 58 insertions, 0 deletions
diff --git a/doc/bugs/encryption_key_is_surprising/comment_5_cd7cbf0c0ee9cafec344dfbf1acd9590._comment b/doc/bugs/encryption_key_is_surprising/comment_5_cd7cbf0c0ee9cafec344dfbf1acd9590._comment
new file mode 100644
index 000000000..4e7635402
--- /dev/null
+++ b/doc/bugs/encryption_key_is_surprising/comment_5_cd7cbf0c0ee9cafec344dfbf1acd9590._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://kaizer.se/"
+ nickname="ulrik.sverdrup"
+ subject="GPG Cipher Algo"
+ date="2013-03-06T04:53:06Z"
+ content="""
+The GPG cipher algorithm is user configurable (unless annex overrides it) the best way to set it is personal-cipher-preferences. Annex' job is simply to provide enough key material for any viable GPG option (so 256 bits of random data). Also note that GPG's string-to-key \"s2k\" algorithm is an iterated application SHA-1 (also this can be configured). For a quick context, it will use a strength number (for example count=128*1024) and it will hash as many iterations as [count]/[key byte length].
+"""]]
diff --git a/doc/bugs/encryption_key_is_surprising/comment_6_01381524114d885961704acc3f172536._comment b/doc/bugs/encryption_key_is_surprising/comment_6_01381524114d885961704acc3f172536._comment
new file mode 100644
index 000000000..21898b522
--- /dev/null
+++ b/doc/bugs/encryption_key_is_surprising/comment_6_01381524114d885961704acc3f172536._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://kaizer.se/"
+ nickname="ulrik.sverdrup"
+ subject="comment 6"
+ date="2013-03-06T05:30:16Z"
+ content="""
+I'm not very clear, sorry. S2K is not iterative in the way for example PBKDF2 is. It will hash a very long repetition of salt + passphrase + salt + passphrase etc in one go. The repetition of this happens if more key bits than the hash digest size are needed.
+"""]]
diff --git a/doc/bugs/git-annex_dropunused_has_no_effect/comment_4_f05a9a3760858c5ee5c98dd8ab059c28._comment b/doc/bugs/git-annex_dropunused_has_no_effect/comment_4_f05a9a3760858c5ee5c98dd8ab059c28._comment
new file mode 100644
index 000000000..9e18696b1
--- /dev/null
+++ b/doc/bugs/git-annex_dropunused_has_no_effect/comment_4_f05a9a3760858c5ee5c98dd8ab059c28._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/2grhJvAC049fJnvALDXek.6MRZMTlg--#eec89"
+ nickname="John"
+ subject="comment 4"
+ date="2013-03-05T22:43:12Z"
+ content="""
+Ah, thanks Joey, that explains it. An error message to that effect would be great!
+"""]]
diff --git a/doc/bugs/three_way_sync_via_S3_and_Jabber/comment_10_fc5ec5505f141bb9135e772d1094bc4d._comment b/doc/bugs/three_way_sync_via_S3_and_Jabber/comment_10_fc5ec5505f141bb9135e772d1094bc4d._comment
new file mode 100644
index 000000000..8389641a8
--- /dev/null
+++ b/doc/bugs/three_way_sync_via_S3_and_Jabber/comment_10_fc5ec5505f141bb9135e772d1094bc4d._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 10"
+ date="2013-03-06T20:35:43Z"
+ content="""
+I've been revisiting the XMPP stuff this week, and today I fixed at least 3 problems that would keep XMPP sync from happening reliably. This would affect machines that are using XMPP and are sometimes disconnected from the net (or suspended). Nothing caused a sync to happen when restarting the assistant, or resuming from a network disconnection. This could result in both files not showing up, and file contents not being transferred, depending on the case hit.
+
+I think it explains everything in this bug report, hopefully.
+"""]]
diff --git a/doc/forum/Difference_between_copy__44___move_and_get__63__.mdwn b/doc/forum/Difference_between_copy__44___move_and_get__63__.mdwn
new file mode 100644
index 000000000..a94281a1f
--- /dev/null
+++ b/doc/forum/Difference_between_copy__44___move_and_get__63__.mdwn
@@ -0,0 +1,24 @@
+I'm starting to experiment with git annex. I'd like to use it for a centralized git repo that will be checked out often, but the clones will rarely need some large binary files (used for testing). Therefore, I've set up a centralized/bare git repo and a clone of that repo using the instructions at [centralized_git_repository_tutorial](http://git-annex.branchable.com/tips/centralized_git_repository_tutorial/) and [bare_repositories](http://git-annex.branchable.com/bare_repositories/). I've added some files to the annex in the clone.
+
+I'm struggling to understand the difference between copy, move, and get. Here's a sequence of commands:
+
+ >> git annex add shared/1bel.maegz
+ >> git commit -m "added first file"
+ >> git push
+ >> git annex move shared/1bel.maegz --to origin
+ ## Now it no longer exists in my local repo
+ >> git annex get shared/1bel.maegz
+ fails.
+ >> git annex get shared/1bel.maegz --from origin
+ fails.
+ >> git annex copy shared/1bel.maegz --from origin
+ fails.
+ >> git annex move shared/1bel.maegz --from origin
+ succeeds! Now I have the file in my clone.
+
+Each failure message is:
+
+ fatal: Could not switch to '../.git/annex/objects/W8/gZ/SHA256-s99196--62874e9b58e652c9c01e796c2bf38b2234a80e0cef95c185bb7f0857d9765df2': No such file or directory
+ git-annex: <file descriptor: 6>: hGetLine: end of file
+
+How are copy, move, and get different? Which one *should* I be using to move my large data into the central (bare) repo? Will it then be available to other clones?