Earlier quoted context omitted.
There's a reason you say that with a throwaway account. Even you know it's shameful.
It's probably Elon Musk.
[flagged]
Git at any scale
121–128 of 128 posts
Re: Git at any scale
#122Re: Git at any scale
#123The problem is that Musk acquired Cursor and therefore Cursor has zero credibility. I don't care about what they say because of who they sold out to
Because politics?
Re: Git at any scale
#124The key part: they decided to use the unchanged git codebase as their building block. Likely assuming that the people who wrote the Linux kernel probably knew what they were doing. That explains some features that look bizarre from the generic distributed-database perspective. I think the author has had this argument many times, because he reiterates it several times in the post. The rest follows from it.
This was what stood out to me, too! And this:
> Packfiles are the fundamental building block of Git storage and Git networking.
(emphasis mine)
> His approach was storing the objects in a distributed hash table. This was only possible thanks to JGit, a custom Git implementation in Java. Like any good ol' Java library, JGit provides enough interfaces and factories and interface factories to abstract all the details of a normal Git repository, including replacing its on-disk packfiles with a DHT. Although the system worked and results were good enough for normal Git operations, the limitations of the Git protocol (which again, require packfiles to be sent over the network regardless of how you store data on the server) made the git clone performance bad enough to discard the design altogether.
Looks like Java enterprise design patterns aren't all bad after all :-) and the git ecosystem would have profited from a bit of abstraction and separation of concerns here, where network protocol, git domain model, and storage layer are evolved somewhat independently. The domain model is what everyone in the ecosystem needs to agree on, the network protocol is what at least the given local & remote host need to agree on, but storage is mainly a local concern.
Of course the question is whether git would have today's market and mind share if they had gone down that path. The ecosystem would be a lot more heterogeneous, evolving network protocol would probably take much longer, etc.
Re: Git at any scale
#125GitHub’s scaling problem is handling huge numbers of relatively small repos at high concurrency. This is not the same problem as Google, Microsoft, Meta et al who have terabyte-scale monorepos, and all have lazy-load solutions to create virtual clones where only the parts you are working on are loaded onto local disk. Microsoft Windows moved to GitHub some time ago and they used the filesystem approach OP dismisses too blithely:
Re: Git at any scale
#126[dead]
Re: Git at any scale
#127Remember, don't put large objects in cnt, it makes it a real pain later.
Can't edit: Looks like they edited this page after the fact[1]: It directly said:
> Continuity (cnt for short) is the git storage system [...]
I guess someone realized that turned this into even more of a joke than it already is.
[1]: https://web.archive.org/web/20260818210312/https://cursor.co...
Re: Git at any scale
#128There’s a trend of doing impressive things by pushing many of the hard problems into S3 and assuming S3 “just works”, then not bothering to explain how S3 works. I guess we do the same thing all the time with other miraculous solutions to hard problems, like assuming that superscalar out-of-order processors “just work”, but in cases like this it makes for an unsatisfying explanation. Especially because S3 is a propri…
Are there any in-depth technical write-ups on S3 that you would recommend reading on S3 to anyone who _does_ want to get into that abstraction?