Comment by kpcyrd
1 month ago
The author seems a little lost tbh, it's starting with "your users should not all clone your database" which I definitely agree with, but that doesn't mean you can't encode your data in a git graph.
It then digresses into implementation details of Github's backend implementation (how is 20k forks relevant?), then complains about default settings of the "standard" git implementation. You don't need to checkout a git working tree to have efficient key value lookups. Without a git working tree you don't need to worry about filesystem directory limits, case sensitivity and path length limits.
I was surprised the author believes the git-equivalent of a database migration is a git history rewrite.
What do you want me to do, invent my own database? Run postgres on a $5 VPS and have everybody accept it as single-point-of-failure?
> Run postgres on a $5 VPS and have everybody accept it as single-point-of-failure
Oh how times have changed. Yes, maybe run two $5 VPSs behind a load balancer for HA so you can patch and then put a CDN in front of it to serve the repository content globally to everyone. Sign the packages cryptographically so you can invite people in your community to become mirrors.
How do people think PyPI, RubyGems, CPAN, Maven Central, or distro Packages work?
Sure let me put all that on my credit card because some guy doesn't like git.
The situation that PyPi is in is clearly worse: https://stackoverflow.com/questions/39537938/how-do-i-downlo...
You wouldn't be the one paying for it, like PyPi you would upload your package to them.
When you bootstrap your package ecosystem using git forges for hosting there's no index at all so I'm not really sure what the argument is.
1 reply →