3 ms·
> This should make pushes much faster as you have basically infinitely scalable writes. However it does make pulls more difficult. I bet GitHub has much more r
by Denvercoder9 6y ago
> This should make pushes much faster as you have basically infinitely scalable writes. However it does make pulls more difficult.
I bet GitHub has much more read traffic than write traffic, so this trade-off does not make sense.
- random5634 6y agoSeriously, imagine the compute and requests costs to assemble a large git pull.
- cordite 6y agoSounds a lot like this here https://github.com/Homebrew/brew/pull/9383 https://github.com/Homebrew/brew/pull/9383
- kevincox 6y agoI said "difficult" not expensive. Once you assembled the packfiles (much like they do today) it should be roughly the same cost.
- WorldMaker 6y agoYes and I would also imagine that the trade-offs between writing a proprietary object storage and reusing the battle-tested object storage that everyone else uses would have been considered as well. It seems like the sort of thing that would be an interesting open source research topic if you could build an object database for git that performs better than its packed in filesystem object store. But it's probably not something you want to do as a proprietary project with fewer eyeballs on its performance trade-offs and more engineering work every time git slightly changes its object storage behavior which would remain tuned for the filesystem object store because it was entirely unaware of your efforts.