| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
| |
| |
| | |
This commit was sponsored by Thom May on Patreon.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In case the repo on the peer changes uuid (eg by a new repo being moved
into place).
Also, added some warning messages when unable to communicate with a
peer.
This commit was sponsored by Anthony DeRobertis on Patreon.
|
| | |
| |
| |
| |
| |
| | |
This also tests that we can connect to the peer.
This commit was sponsored by Jeff Goeke-Smith on Patreon.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Not tested at all, but it just might work.
Only known problem is that progress is not updated when storing to a P2P
remote.
This commit was sponsored by Nick Daly on Patreon.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This is needed in addition to StoreContent, because retrieveKeyFile can
be used to retrieve to different destination files, not only the tmp
file for a key.
This commit was sponsored by Ole-Morten Duesund on Patreon.
|
| | |
| |
| |
| |
| |
| |
| | |
Similar to GCrypt remotes, P2P remotes have an url, so Remote.Git has to
separate them out and handle them, passing off to Remote.P2P.
This commit was sponsored by Ignacio on Patreon.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
(This was already done in v6 mode and direct mode.)
|
| | |
| |
| |
| | |
mdwn2man gets confused as `command` spanning multiple lines..
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Would have liked to make the Parser parse the file and key pairs, but it
seems that optparse-applicative is unable to handle eg:
many ((,) <$> argument <*> argument)
This commit was sponsored by Thomas Hochstein on Patreon.
|
| | | |
|
| | | |
|
| | |\ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* rmurl: Multiple pairs of files and urls can be provided on the
command line.
* rmurl: Added --batch mode.
This commit was sponsored by Trenton Cronholm on Patreon.
|
| | |/
| |
| |
| | |
It also still reads from stdin when none are specified.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |\ |
|
| | | |
| | |
| | |
| | | |
and some misc updates
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ReadContent can't update the log, since it reads lazily. This part of
the P2P monad will need to be rethought.
Associated files are heavily sanitized when received from a peer;
they could be an exploit vector.
This commit was sponsored by Jochen Bartl on Patreon.
|
| | |
| |
| |
| | |
This will allow updating transfer logs with the uuid.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Untested, and it does not yet update transfer logs.
Verifying transferred content is modeled on git-annex-shell recvkey.
In a direct mode or annex.thin repository, content can change while it's
being transferred. So, verification is always done, even if annex.verify
would normally prevent it.
Note that a WORM or URL key could change in a way the verification
doesn't catch. That can happen in git-annex-shell recvkey too. We don't
worry about it, because those key backends don't guarantee preservation
of data. (Which is to say, I worried about it, and then convinced myself
again it was ok.)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Each worker thread needs to run in the Annex monad, but the
remote-daemon's liftAnnex can only run 1 action at a time. Used
Annex.Concurrent to deal with that.
P2P.Annex is incomplete as of yet.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
It's possible, in direct or thin mode, that an object file gets
truncated or appended to as it's being sent. This would break the
protocol badly, so make sure never to send too many bytes, and to
close the protocol connection if too few bytes are available.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
test failures were being ignored for complex reasons, new autobuilder broke that; bring it back
|
| | |\ |
|
Joey Hess
0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730
alpernebbi
Daniel Brooks
https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4
marek@33e8ba4fbc201af14a2badcc0656024401f5c916
justin.lebar@7a36fcafc322d9a381e89f08ab6289033c6dde91
lorenzo@a77fdbe826df1c175cbd30ed050312ccf7b7fc7b
https://openid.stackexchange.com/user/3ee5cf54-f022-4a71-8666-3c2b5ee231dd