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

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

Browse source
This commit is contained in:
Joey Hess 2017-03-30 11:31:38 -04:00
commit a7b068f271
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 65 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
doc/bugs/gcrypt_remote__58___every_sync_uploads_huge_manifest.mdwn Normal file
View file

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

25
doc/tips/Systemd_unit/comment_1_06399a293f08401032bef1b94f05547c._comment Normal file
View file

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

12
doc/tips/peer_to_peer_network_with_tor/comment_3_9fc514cf5273dd4a29dfb3ab81346425._comment Normal file
View file

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