Merge branch 'master' into no-xmpp

This commit is contained in:
Joey Hess 2016-12-24 14:48:51 -04:00
commit ab66bbfeb6
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
377 changed files with 7442 additions and 875 deletions

View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="David_K"
avatar="http://cdn.libravatar.org/avatar/09dd8544695feb9b8d8ee54e4ff0168d"
subject="comment 28"
date="2016-11-16T01:28:14Z"
content="""
I'd like to reiterate a question that was unanswered above:
Is there a way to tell the S3 backend to store the files as they are named locally, instead of by hashed content name? i.e., I've annexed foo/bar.txt and annex puts it in s3 as mybucket.name/foo/bar.txt instead of mybucket.name/GPGHMACSHA1-random.txt
"""]]

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="davidriod@e75b369a4b1cced29c14354bce7493c61f00b1c7"
nickname="davidriod"
avatar="http://cdn.libravatar.org/avatar/d6e327bd88b88802d6f0c20c83f682a2"
subject="Sharing rsync special remote between repository"
date="2016-11-24T19:23:42Z"
content="""
I was wondering if it is possible to share a rsync special remote between repository which are not parented in any way. The use case would be that even if these repositories are not related at all they still may contains the same binary file. It would be useful to have a single rsync remote in order to reduce space usage. I think it could work as the object names are based on their checksum, but I wonder if anyone has already try that ?
"""]]

View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="joey"
subject="""comment 15"""
date="2016-12-13T16:43:42Z"
content="""
@davidriod you can do things like this with special remotes, as long
as the special remotes are not encrypted.
I don't really recommend it. With such a shared special remote R and two
disconnected git repos -- call them A and B, some confusing situations can
occur. For example, the only copies of some files may be
on special remote R and git repo B. A knows about the copy in R, so
git-annex is satisfied there is one copy of the file. But now, B can drop
the content from R, which is allowed as the content is in B. A is then left
unable to recover the content of the files at all, since they have been
removed from R.
Better to connect the two repositories A and B, even if you do work in
two separate branches. Then if a file ends up located only on B, A will be
able to say where it is, and could even get it from B (if B was set up as a
remote).
"""]]

View file

@ -0,0 +1,10 @@
git-annex can communicate over the Tor network. This allows direct
communication between git-annex repositories, no matter where they are
located.
A git remote using tor has an url that looks like
`tor-annex::2lssjzicvsxkdc2v.onion:19984`
To set this up, use [[git-annex-enabletor]] and [[git-annex-p2p]],
and run [[git-annex-remotedaemon]] to serve the Tor hidden service.
It's explained in detail in [[tips/peer_to_peer_network_with_tor]].