summaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
authorGravatar Joey Hess <joeyh@joeyh.name>2017-03-30 11:31:38 -0400
committerGravatar Joey Hess <joeyh@joeyh.name>2017-03-30 11:31:38 -0400
commit48f3b59749fd0c203afed1e050cd0c33abff2f3b (patch)
tree5a778398d3caddd4494e260225fe884e7be4a8b2 /doc/bugs
parent17f62aeadafec7944bdbb7803a869f9b971c6204 (diff)
parentda97139d970e6fba38212272e1a30a6724d44b09 (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn28
1 files changed, 28 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)