86e9e88530Added git-remote-p2p-annex, which allows git pull and push to P2P networks provided by external commands. This is a refactor of git-remote-tor-annex, and should just work. Except possibly for quirks with the address parsing. I've checked that the address parsing basically works. One thing I don't understand is why git-remote-tor-annex removes "/*" from the end of the address. The git history does not provide any hints. So I didn't make git-remote-p2p-annex do the same. Maybe that is needed in some situation? But, a P2P address could contain "/", so removing it would be a problem. I can't see anything in gitremote-helpers(7) about why the url might get such a thing added to the end of it. My guess is that is not needed for tor either (but does no harm there since onion addresses never contain "/"). At this point, the implementation of generic P2P transports needs only remotedaemon support. |
||
|---|---|---|
| .. | ||
| git | ||
| git-annex | ||
| git-annex-shell | ||
| git-annex-webapp | ||
| git-receive-pack | ||
| git-remote-annex | ||
| git-shell | ||
| git-upload-pack | ||
| README | ||
| runshell | ||
You can put this directory into your PATH, or symlink the programs in this directory to anyplace already in your PATH, and use git-annex the same as if you'd installed it using a package manager. Or, you can use the runshell script in this directory to start a shell that is configured to use git-annex and the other utilities included in this bundle. This should work on any Linux system of the appropriate architecture. More or less. How it works: This directory tree contains a lot of libraries and programs that git-annex needs. But it's not a chroot. Instead, runshell sets a lot of environment variables to cause files from here to be used, and a shim around the binaries arranges for them to be run with the libraries in here. It shouldn't even be dependent on the host system's glibc libraries. All that's needed is a kernel that supports the glibc included in this bundle.