If I'm reading this right, this is (really solid) future planning but won't help with the current outages?
I'd have thought so from the headline + initial content but then they say that the horizontal scale techniques are basically carrying over from the existing architecture (where it seems the problem is?) and this is mostly to help with what they call "vertical scale" (intra-repo scalability). They also admit right after that the most active repos today will receive short bursts of at most dozens of writes.
So this seems like really useful planning for a near future that likely helps prevent more issues but isn't really meant to help current issues. Am I reading this right?
Of course improvements like this are always useful either way. Not dunking here at all.
show comments
dwm
This looks a lot like Cursor's Continuity, though Github are reporting an order of magnitude greater write throughput.
Agent scale is definitely on the mind around industry, I wonder what github folks would say in response to https://www.anthropic.com/research/redesigning-source-contro.... It's an interesting read to step back and consider source control from first principles and rebalance the tradeoffs for what qualities matter in this new regime.
show comments
rochacon
So that is why I got a bunch of 500's during push this week :)
Hope it helps improve reliability, it was getting hard to defend GitHub with all the recent outages.
mitxela
You could also just ban people who spam you and consume immense amounts of server time. Or make them pay for the server time.
petervandijck
I wonder if they’re working on a non git version forward looking for agents as well
show comments
fnord77
Which repo were they referring to that was growing too big vertically?
show comments
crote
Sorry, but thousands of pushes per second, per repository?! In what world could that possibly seem like a sound idea?
Sure, it's nice that you can technically handle it, but to me it sounds like at that point something has gone absolutely horribly wrong in the way you set up your agents. Last time I checked, GitHub was intended as a platform to upstream finished work items, not a realtime cross-agent chat channel.
Handling thousands of git pushes per second implies thousands of issues, thousands of PRs, tens of thousands of comments, thousands of Actions runs, and dozens of releases. How's that part of their infra going to scale?
How about introducing rate limits instead, nudging people to not have agents push every individual single-line changes to GH, but instead have them collaborate as a local cluster and only upstreaming PR-sized chunks of finished work?
If you still need thousands of pushes per second you'd be looking at millions of lines of code, and at that point you're looking at an insane monorepo which is growing at a rate of terabytes per day, and which basically instantly becomes unusable due to being impossible to clone or check out.
show comments
Traubenfuchs
> sending 7,200 pushes per second to a repo
Imagine the token costs!
My company with about 60 devs in the backend dev slack channel probably produces less commits per year together.
Does my company already belong to the permanent AI underclass?
usr1106
Based on Azure... Isn't that one of the more unreliable clouds in the market?
it’s pretty ironic we got all the complexity of distributed source control with all of the drawbacks of centralisation
show comments
bob1029
I think perforce might be the better VCS if you intend to have a bunch of autonomous agents attempt to collaborate over one big pile.
Multiple terabytes is no problem out of the box. You get exclusive locking of files. You can easily take partial checkouts of the monolith. Centralization is a feature in this particular context. Git works great if the need for coordination is moderate. If you've got thousands of automated developers with their hands in the cookie jar, exclusive locks start to look really compelling. Perforce sucks with a highly distributed team, but in the case of an AI agent swarm we presumably have the ability to instantly nuke an agent's checkout if needed. I don't have to contact the agent and wait for them to get out of bed.
show comments
dizhn
"we’ve been building it underneath GitHub while it keeps running."
Holding on for dear life and failing is more like it.
chjail-11
As if more developers means better code.
Wasn't it Bonhoeffer who said stupidity is when smart people don't question authority?
Most of this is similar to what https://enroute.sh already did scaling Git. https://enroute.sh/blog/everyone-is-doing-git-on-s3-wrong
If I'm reading this right, this is (really solid) future planning but won't help with the current outages?
I'd have thought so from the headline + initial content but then they say that the horizontal scale techniques are basically carrying over from the existing architecture (where it seems the problem is?) and this is mostly to help with what they call "vertical scale" (intra-repo scalability). They also admit right after that the most active repos today will receive short bursts of at most dozens of writes.
So this seems like really useful planning for a near future that likely helps prevent more issues but isn't really meant to help current issues. Am I reading this right?
Of course improvements like this are always useful either way. Not dunking here at all.
This looks a lot like Cursor's Continuity, though Github are reporting an order of magnitude greater write throughput.
https://cursor.com/blog/git-at-any-scale
Agent scale is definitely on the mind around industry, I wonder what github folks would say in response to https://www.anthropic.com/research/redesigning-source-contro.... It's an interesting read to step back and consider source control from first principles and rebalance the tradeoffs for what qualities matter in this new regime.
So that is why I got a bunch of 500's during push this week :)
Hope it helps improve reliability, it was getting hard to defend GitHub with all the recent outages.
You could also just ban people who spam you and consume immense amounts of server time. Or make them pay for the server time.
I wonder if they’re working on a non git version forward looking for agents as well
Which repo were they referring to that was growing too big vertically?
Sorry, but thousands of pushes per second, per repository?! In what world could that possibly seem like a sound idea?
Sure, it's nice that you can technically handle it, but to me it sounds like at that point something has gone absolutely horribly wrong in the way you set up your agents. Last time I checked, GitHub was intended as a platform to upstream finished work items, not a realtime cross-agent chat channel.
Handling thousands of git pushes per second implies thousands of issues, thousands of PRs, tens of thousands of comments, thousands of Actions runs, and dozens of releases. How's that part of their infra going to scale?
How about introducing rate limits instead, nudging people to not have agents push every individual single-line changes to GH, but instead have them collaborate as a local cluster and only upstreaming PR-sized chunks of finished work?
If you still need thousands of pushes per second you'd be looking at millions of lines of code, and at that point you're looking at an insane monorepo which is growing at a rate of terabytes per day, and which basically instantly becomes unusable due to being impossible to clone or check out.
> sending 7,200 pushes per second to a repo
Imagine the token costs!
My company with about 60 devs in the backend dev slack channel probably produces less commits per year together.
Does my company already belong to the permanent AI underclass?
Based on Azure... Isn't that one of the more unreliable clouds in the market?
Edit: https://assets.theregister.com/2026/04/04/azure_talent_exodu... The blog post that story is based on was also on HN.
Edit2: https://news.ycombinator.com/item?id=47616242 (1297 points)
So we can have one more 9?
it’s pretty ironic we got all the complexity of distributed source control with all of the drawbacks of centralisation
I think perforce might be the better VCS if you intend to have a bunch of autonomous agents attempt to collaborate over one big pile.
Multiple terabytes is no problem out of the box. You get exclusive locking of files. You can easily take partial checkouts of the monolith. Centralization is a feature in this particular context. Git works great if the need for coordination is moderate. If you've got thousands of automated developers with their hands in the cookie jar, exclusive locks start to look really compelling. Perforce sucks with a highly distributed team, but in the case of an AI agent swarm we presumably have the ability to instantly nuke an agent's checkout if needed. I don't have to contact the agent and wait for them to get out of bed.
"we’ve been building it underneath GitHub while it keeps running."
Holding on for dear life and failing is more like it.
As if more developers means better code. Wasn't it Bonhoeffer who said stupidity is when smart people don't question authority?