| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
And for tab completion, by not unnessessarily statting paths to remotes,
which used to cause eg, spin-up of removable drives.
Got rid of the remotes member of Git.Repo. This was a bit painful.
Remote.Git modifies the list of remotes as it reads their configs,
so still need a persistent list of remotes. So, put it in as
Annex.gitremotes. It's only populated by getGitRemotes, so commands
like examinekey that don't care about remotes won't do so.
This commit was sponsored by Jake Vosloo on Patreon.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Fourth or fifth try at this and finally found a way to make it work.
Absurd amount of busy-work forced on me by change in cabal's behavior.
Split up Utility modules that need posix stuff out of ones used by
Setup. Various other hacks around inability for Setup to use anything
that ifdefs a use of unix.
Probably lost a full day of my life to this.
This is how build systems make their users hate them. Just saying.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Clean up some uses of showStart with "" for the file,
or in some cases, a non-filename description string. That would
generate bad json, although none of the commands doing that
supported --json.
Using "" for the file resulted in output like "foo rest";
now the extra space is eliminated.
This commit was sponsored by Fernando Jimenez on Patreon.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Wormhole pairing will start to provide an appid to wormhole on 2021-12-31.
An appid can't be provided now because Debian stable is going to ship a
older version of git-annex that does not provide an appid. Assumption is
that by 2021-12-31, this version of git-annex will be shipped in a Debian
stable release. If that turns out to not be the case, this change will need
to be cherry-picked into the git-annex in Debian stable, or its wormhole
pairing will break.
This commit was sponsored by Thomas Hochstein on Patreon.
|
| |
|
|
| |
This commit was sponsored by Riku Voipio.
|
| | |
|
| |
|
|
|
| |
This is a big scary change. I have convinced myself it should be safe. I
hope!
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It builds. I have not tried to run it yet. :)
This commit was sponsored by Jake Vosloo on Patreon.
|
| |
|
|
|
|
|
|
| |
This reverts commit 6aa7e136b5d246228723f4c9996bda11f66c4445.
On second thought, this was an overcomplication of what should be the
lowest-level primitive. Let's build bi-directional links at the pairing
level with eg magic wormhole.
|
| |
|
|
| |
This commit was sponsored by Fernando Jimenez on Patreon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both the local and remote git repositories get remotes added
pointing at one-another.
Makes pairing twice as easy!
Security: The new LINK command in the protocol can be sent repeatedly,
but only by a peer who has authenticated with us. So, it's entirely safe to
add a link back to that peer, or to some other peer it knows about.
Anything we receive over such a link, the peer could send us over the
current connection.
There is some risk of being flooded with LINKs, and adding too many
remotes. To guard against that, there's a hard cap on the number of remotes
that can be set up this way. This will only be a problem if setting up
large p2p networks that have exceptional interconnectedness.
A new, dedicated authtoken is created when sending LINK.
This also allows, in theory, using a p2p network like tor, to learn about
links on other networks, like telehash.
This commit was sponsored by Bruno BEAUFILS on Patreon.
|
| |
|
|
| |
used.
|
| |
|
|
|
|
| |
So we get some useful error messages when things fail.
This commit was sponsored by Peter Hogg on Patreon.
|
| | |
|
| |
|
|
|
|
| |
This also tests that we can connect to the peer.
This commit was sponsored by Jeff Goeke-Smith on Patreon.
|
| |
|
|
| |
This commit was sponsored by Riku Voipio.
|
| |
|
Joey Hess