5c3636037b
A warning message is unsatisfying. But erroring out is too hard a failure, especially since it may well work fine if the user has enabled passwordless ssh. I did think about falling back to one ssh connection at a time in this case, but it would have needed a rework of every ssh call, which seems far overboard for such a niche problem. There's no single place where git-annex runs ssh, so no one place that it could block a concurrent call on a semaphore. And, even if it did fall back to one ssh connection at a time, it seems to me that doing so without warning the user about the problem just invites bug reports like "git-annex is ignoring my -J2 and only doing one download at a time". So a warning is needed, and I suppose is good enough. |
||
---|---|---|
.. | ||
git | ||
git-annex | ||
git-annex-shell | ||
git-annex-webapp | ||
git-receive-pack | ||
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, including git, gpg, rsync, ssh, etc. 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.