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

3 files changed, 65 insertions, 0 deletions

diff --git a/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn
new file mode 100644
index 000000000..f136b25b3
--- /dev/null
+++ b/doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn
@@ -0,0 +1,28 @@
+### Please describe the problem.
+
+every sync (without --content) to a gcrypt remote uploads huge amount of data (>100MB) when doing
+
+    gcrypt: Requesting manifest signature
+
+It seems to upload a special git object every time, even if this object is apparently unchanged. An unencrypted, regular git remote is much faster and does not transfer such amounts of data.
+
+I wonder if this can be changed, because it renders that gcrypt remote almost unusable via ADSL upstream. In my case the sync duration was 36 Minutes, uploading ~250MB.
+
+### What steps will reproduce the problem?
+
+Have a (bare) gcrypt remote and a rather big (mine has 77668 keys, annexing 769GB of files) git-annex repository. Sync with the gcrypt remote. When pushing, the message "gcrypt: Requesting manifest signature" appears, and a very large amount of data is transferred to the remote, while the process chain
+
+    git-remote-gcrypt mygcrypt ssh://mygcrypt/home/my/annex
+     git push --quiet -f ssh://mygcrypt/home/my/annex refs/gcrypt/gitception+:refs/heads/master
+      ssh mygcrypt git-receive-pack '/home/my/annex'
+       git pack-objects --all-progress-implied --revs --stdout --thin --delta-base-offset -q
+
+is running. The upload of the actual changeset starts after this, the processes look the same, transferring again a more or less big amount of data (depending on the changeset size, I guess).
+
+### What version of git-annex are you using? On what operating system?
+
+6.20170101-1 on Debian Stretch (9.0)
+
+### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
+
+git-annex is great and revolutionized my file organization and backup structure (if they were even existing before)
diff --git a/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment b/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment
new file mode 100644
index 000000000..7af170ef1
--- /dev/null
+++ b/doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment
@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="oberix@c7a19cddb1663df0c612a979b9d13b0d67f1f69a"
+ nickname="oberix"
+ avatar="http://cdn.libravatar.org/avatar/e8b871f3d0bf96df9a3fc8cdca7abe09"
+ subject="autostart and foreground together doesn't seem to work"
+ date="2017-03-30T10:43:18Z"
+ content="""
+With systemd using `--autostart --foreground` either ignore foreground or quit immediatelly.
+
+I managed to have the process stay alive with `RemainAfterExit=on`:
+
+    [Service]
+    User=%i
+    ExecStart=/usr/bin/git-annex assistant --autostart --foreground
+    ExecStop=/usr/bin/git-annex assistant --autostop
+    RemainAfterExit=on
+    Restart=on-failure
+    RestartSec=5
+
+but git-annex processes does not maintain the `--foreground` option which is causing a lot of zombies in the long period (not totally clear why).
+
+My current solution is to have a service for each annex repository and avoid `--autosart` but this is annoying because it require to pass the path as `%I` and wrap git-annex in bash script to get the repo owner as the user.
+
+
+"""]]
diff --git a/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment b/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment
new file mode 100644
index 000000000..583495994
--- /dev/null
+++ b/doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="anarcat"
+ avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
+ subject="onion-grater"
+ date="2017-03-30T14:49:12Z"
+ content="""
+you may want to consider using [onion-grater][] to limit possible escalations in the use of that control port:
+
+ [onion-grater]: https://github.com/Whonix/onion-grater
+
+RFP: [[!debbug 859125]]
+"""]]