Our great sponsors
-
-
libgit2
A cross-platform, linkable library implementation of Git that you can use in your application.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
In addition, in order to migrate your GitHub issues to Radicle (which the above doesn't cover), there's this command-line tool [1] that should get you most - if not all - of the way there.
Migrating GitHub Pull Requests (PRs) to Radicle Patches is somewhat more involved, but that should still be possible (even if it involves some loss of information along the way, due to potential schema mismatches) ...
[1] - https://github.com/cytechmobile/radicle-github-migrate
Everything that is replicated on the network is stored as a Git object, using the libgit2[0] library. This library uses hardened SHA-1 internally, which is called sha1dc (for "detect collision").
[0]: https://github.com/libgit2/libgit2/blob/ac0f2245510f6c75db1b...
I'm curious if you (or anyone) had a chance to use Mango (https://github.com/axic/mango) before it was abandoned?
You can already use it with git-annex to store binaries using the git-annex-remote-git-aafs[1] special remote.
Although I would be careful and make sure you understand what it is doing to your branch namespace. Even though in the worst case it would not save any space over directly committing binaries, they are in orphan branches that can be pruned without rewriting history.
But even so, you can just use any number of git-annex special remotes to bypass using git for sharing files.
They may eventually add first-party support for git-annex. But nothing is stopping you from using it now.
[1]: https://github.com/domo141/git-annex-remote-git-aafs
This is an overreaction, almost to the point of absurdity.
Risks inherent to pipe installers are well understood by many. Using your logic, we should abandon Homebrew [1] (>38k stars on GitHub), PiHole [2] (>46k stars on GitHub), Chef [3], RVM [4], and countless other open source projects that use one-step automated installers (by piping to bash).
A more reasonable response would be to coordinate with the developers to update the docs to provide alternative installation methods, rather than throwing the baby out with the bathwater.
[1] https://brew.sh/
[2] https://github.com/pi-hole/pi-hole
[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
[4] https://rvm.io/rvm/install
This is an overreaction, almost to the point of absurdity.
Risks inherent to pipe installers are well understood by many. Using your logic, we should abandon Homebrew [1] (>38k stars on GitHub), PiHole [2] (>46k stars on GitHub), Chef [3], RVM [4], and countless other open source projects that use one-step automated installers (by piping to bash).
A more reasonable response would be to coordinate with the developers to update the docs to provide alternative installation methods, rather than throwing the baby out with the bathwater.
[1] https://brew.sh/
[2] https://github.com/pi-hole/pi-hole
[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
[4] https://rvm.io/rvm/install
A friend of mine wrote a similar tool. https://github.com/nolash/piknik.