Git at any scale • Hacker News Board

Re: Git at any scale

#31

Post by newspaper1 » Thu, Aug 20, 2026, 6:19 PM UTC

throwitaway222 wrote: post #28

bryanlarsen wrote: post #15

Earlier quoted context omitted.

[flagged]

tired of this

Well, there's going to be a lot more of it. You can't be an outright ultra-right wing racist and expect that it doesn't cause brand damage. It never made business sense for Musk to act the way he does, but he couldn't help himself. Do not expect people to just be ok with it.

Re: Git at any scale

#32

Post by mlnj » Thu, Aug 20, 2026, 6:41 PM UTC

throwitaway222 wrote: post #28

bryanlarsen wrote: post #15

Earlier quoted context omitted.

[flagged]

tired of this

There's a reason you say that with a throwaway account. Even you know it's shameful.

Re: Git at any scale

#33

Post by croes » Thu, Aug 20, 2026, 6:44 PM UTC

throwitaway222 wrote: post #28

bryanlarsen wrote: post #15

Earlier quoted context omitted.

[flagged]

tired of this

Just like with climate change, the problems Elon creates don’t go away just because people are reminded of them.

He still pushes his agenda, he still has lots of followers who believe his nonsense

Re: Git at any scale

#34

Post by dataplumb3r » Thu, Aug 20, 2026, 6:44 PM UTC

> The productivity cost of five minutes of downtime in your CI system is hard to quantify in dollars, but it is, by any measure, a humongous amount.

Not sure the last month GH had fewer than five minutes of downtime - but I think it's been a while

Re: Git at any scale

#35

Post by dataplumb3r » Thu, Aug 20, 2026, 6:48 PM UTC

eatonphil wrote: post #8

> The "fan-out" is synchronized with a classic consensus algorithm called 3PC (three-phase commit) so that a push is only accepted if a majority of the nodes acknowledge it. Doesn't 3PC require all nodes to agree, not just a majority?

I would think so - outside this sentence the author indicates they're talking about consensus across all members.

IE - the interactive diagram and note about latency being bounded by the slowest replica

Re: Git at any scale

#36

Post by luke5441 » Thu, Aug 20, 2026, 6:49 PM UTC

Took me some thinking to figure out where this design is not optimal.

The first step is to separate the problems. The content addressable object storage and storing the refs. libgit2 has two backends for those already.

Then use appropriate distributed dbs for the two backends. With large scale something like Cassandra for the objects (AP) and FoundationDB (CP) for the refs (or the equivalent Amazon services).

For performance the objects need to be cached locally and requests routed to nodes where the objects are cached locally.

Re: Git at any scale

#37

Post by tonymet » Thu, Aug 20, 2026, 6:55 PM UTC

aeyes wrote: post #30

tonymet wrote: post #29

how does git lock the repo on extreme concurrency? let's say 1000 devs writing to the same repository? eventually you'll have saturation of the resource locking everyone out. When I've worked at big companies they had bespoke SCM that resolved this. But i'm curious about mid size teams that are big enough to overwhelm git but not so that they can rewrite it.

If those 1000 devs write to different branches then you only take a light lock on the branch, usually that is not the problem. The problems start when there is a lot of changes on one branch and usually the first band-aid is to put a commit queue in place. The few very big companies that need even more than that probably aren't going to put their code on a new git hosting provider tomorrow.

that sounds like a practical solution once you reach that size. yeah you're right i think only the refs are locked, the rest of the objects can all be submitted concurrently, so it would be high contention refs/branches that would be a pain point.

Re: Git at any scale

#38

Post by p_l » Thu, Aug 20, 2026, 7:04 PM UTC

luke5441 wrote: post #36

Took me some thinking to figure out where this design is not optimal. The first step is to separate the problems. The content addressable object storage and storing the refs. libgit2 has two backends for those already. Then use appropriate distributed dbs for the two backends. With large scale something like Cassandra for the objects (AP) and FoundationDB (CP) for the refs (or the equivalent Amazon services). For per…

Part of the problem is that the API you're supposed to provide externally depends on git packs which you might have to reconstruct on the fly from such a system.

Re: Git at any scale

#39

Post by warmwaffles » Thu, Aug 20, 2026, 7:09 PM UTC

Very cool write up. But I do have to wonder, is Git the right solution for version control given where we are heading? The commands are all muscle memory for me now at this point, but all the projects I've been working on lately have just all moved to trunk based development, rebasing, and squashing merging feature branches onto main.

I've been working on another project where I have binary files checked in, assets that move or are moved and then changed that git "loses track of" due to the significant change. This just may be me doing silly things like moving a file and then editing it and then committing it and git thinks I deleted it and created a new file.

Re: Git at any scale

#40

Post by speed_spread » Thu, Aug 20, 2026, 7:11 PM UTC

Reading this, I can't come to a conclusion other than "git rapidly starts sucking balls for use cases outside of Linux development". Github started with ze_current_fastness but then ended up recurrently smashing into walls because of it.

They should have just failed to scale git and leave place for the less idiosyncratic bazaar or mercurial to take the lead. These were slower, but would probably have scaled much better in the long term.

Github's core innovation was re-centralizing a decentralized SCM (as per article) by giving it nice web UI and features such as PRs. Oh and also free code hosting space. None of which relied on git's peculiarities.