keb_15 hours ago
I've got this feeling that the endless feature creep of Github has begun to cause rot of core essential features. Up until only recently, the PR review tab performed so poorly it was practically useless for large PRs.
o_m11 hours ago
GitHub isn't focusing on creating a good Git platform anymore, they are an AI company now
hugs8 hours ago
Bets on where everything/everyone goes next? Will it be like the transition from SourceForge to GitHub, where the center of gravity moves from one big place to another big place? Or more like Twitter, where factions split off to several smaller places?
dzader11 hours ago
[dead]
azangru10 hours ago
> I've got this feeling that the endless feature creep of Github has begun to cause rot of core essential features.
Tangential, but... I was so excited by their frontend, which was slowly adopting web components, until after acquisition by Microsoft they started rewriting it in React.
(Design is still very solid though!)
dewey12 hours ago
GitHub in essence is still pretty much the same, there's products that have feature creep but I wouldn't say GitHub does that.
I can't say that I'm having issues with the performance either. I work with large PRs too (Especially if there's vendored dependencies) but I never ran into a show stopping performance issue that would make it "useless".
keb_10 hours ago
> GitHub in essence is still pretty much the same, there's products that have feature creep but I wouldn't say GitHub does that.
I think we're using two different products. Off the top of my head, I can think of Github Projects (the Trello-like feature), Github Marketplace, Github Discussions, the complete revamp of the file-viewer/editor, and all the new AI/LLM-based stuff baked into yet another feature known as Codespaces.
> I can't say that I'm having issues with the performance either. I work with large PRs too
Good for you. I suffered for maybe 4 years from this, and so have many others: https://github.com/orgs/community/discussions/39341
inetknght12 hours ago
> there's products that have feature creep but I wouldn't say GitHub does that.
I remember GitHub from years ago. I still find myself looking for things that were there years ago but have since moved.
Also, GitHub search is (still) comically useless. I just clone and use grep instead.
dunham9 hours ago
I've also loaded repositories into a web instance of vscode (with the '.' shortcut) and done Cmd-Sh-F, which also works better than their search.
davidspiess12 hours ago
I noticed this recently too when using Firefox.
ajsnigrutin11 hours ago
Still doesn't read email, but it's close to that.
paradox4607 hours ago
You can interact with a lot of GitHub via email
sleepybrett9 hours ago
Yeah i've switched to doing pr reviews in goland because their ui is dogshit slow if there are more than like 10 files to diff.
bdcravens15 hours ago
HN sure has changed. A few years ago there would be at least a dozen comments about installing Gitlab, including one major subthread started by someone from Gitlab.
KronisLV11 minutes ago
I've used self-hosted GitLab a bunch at work, it's pretty good there still. In my opinion GitLab CI is also a solid offering, especially for the folks coming from something like Jenkins, doubly so when combined with Docker executors and mostly working with containers.
I used to run a GitLab instance for my own needs, however keeping up with the updates (especially across major versions) proved to be a bit too much and it was quite resource hungry.
My personal stack right now is Gitea + Drone CI + Nexus, though I might move over to Woodpecker CI in the future and also maybe look for alternatives to Nexus (it's also quite heavyweight and annoying to admin).
lrvick15 hours ago
We recommend Codeberg/Forgejo now since it is better in every way, and Gitlab went corpo.
NewJazz15 hours ago
Gitlab was always for profit.
And forgejo doesn't have feature parity at all with gitlab. Neither does github, for that matter.
Just take a look at how to push container images from a cicd pipeline in gitlab vs. Forgejo.
fmbb14 hours ago
What’s the difference?
Pushing images is a oneliner.
NewJazz14 hours ago
In gitlab, yes (well, two lines, login then push). In forgejo, there is no cicd token that gives you scoped access to the built in container registry. You must create a long lived token and add it as a secret to the repo you want to push from.
See here: https://mteixeira.wordpress.com/2025/02/03/my-self-hosted-fo...
[deleted]10 hours agocollapsed
pfcd9 hours ago
> We recommend Codeberg/Forgejo now since it is better in every way...
Lol.
> ...and Gitlab went corpo.
How else will they sustain/maintain such a product and compete with the likes of GitHub? With donations? Good luck.
Elucalidavah15 hours ago
Are those any better than self-hosted gitlab, or do you only mean central-hosted usage?
NewJazz11 hours ago
Codeberg is central hosted so I think they mean in general.
rngecounty6 hours ago
Having tried gitlab, it's a very poor product almost unmaintainable as a self hosted option. Reminds me of Eclipse IDE - crammed with every other unnecessary feature/plugin and the basic features are either very slow or buggy.
At this point Gitlab is just there because being even a small X% of a huge million/billion dollar market is good enough as a company even if the product is almost unusable.
factorialboy15 hours ago
Not just HN, Gitlab has perhaps changed as well.
Tostino15 hours ago
I wouldn't touch Gitlab at this point. I didn't change. They did.
dewey12 hours ago
Which is probably good, as otherwise they would be dead. Building products for self-hosting HN users isn't really a big money maker.
arccy16 hours ago
I guess they let copilot review their code
shakna16 hours ago
Well, the CEO did say to embrace AI or get out of code, 2 days ago... And MS previously said AI is not-optional for their devs...
hiccuphippo16 hours ago
Maybe they are trying vibeops now.
jennyholzer16 hours ago
At Microsoft vibeops is an age old tradition.
esafak7 hours ago
After writing it :)
DeepYogurt9 hours ago
They do actually
rileymichael16 hours ago
did all of the devs leave?
https://www.businessinsider.com/github-ceo-developers-embrac...
ryandrake16 hours ago
> Instead of selling products based on helpful features and letting users decide, executives often deploy scare tactics that essentially warn people they will become obsolete if they don't get on the AI bandwagon. For instance, Julia Liuson, another executive at Microsoft, which owns GitHub, recently warned employees that "using AI is no longer optional."
So many clowns. It's like everyone's reading from the same script/playbook. Nothing says "this tool is useful" quite like forcing people to use it.
bogzz15 hours ago
It definitely feels like the imbecility of the corporate class has reached new levels.
conradfr15 hours ago
AI is not for developers only!
lrvick15 hours ago
AI is not for developers, it is for people that do not want to learn how to be developers but want to be paid like them.
MrGilbert15 hours ago
> It's like everyone's reading from the same script/playbook.
I'd assume that many CEO are driven by the same urge to please the board. And depending on your board, there might be people on it who spend many hours per week on LinkedIn, and see all the success stories around AI, maybe experienced something first hand.
Good news: It's, from my estimate, only a phase. Like when blockchain hit, and everyone wanted to be involved. This time - and that worries me - the ressources involved are more expensive, though. There might be a stronger incentive for people to "get their money back". I haven't thought about the implications yet.
depr11 hours ago
People say this a lot, please the board. But why would so many boards be hype-driven and CEO's be rational? It might just as well be the C-suite themselves who are the source of it.
ryandrake10 hours ago
The CEOs and execs also seem to be feeding and sustaining the hype themselves:
CEO1: "This technology is the biggest technical leap in my lifetime!"
CEO2: "Oh yea? Well, this technology is more useful than electricity!"
CEO3: "Oh yea?? This technology is more impactful than the invention of fire!"
VP1: "This technology is going to really help improve productivity!"
VP2: "Come on! This technology is going to let one person do the work of 100!"
VP3: "Surely you jest! Without using this technology, you might as well not even try to earn a living!"
Eisenstein15 hours ago
It's not like blockchain. Blockchain legitimately made things slower and less useful for dubious benefits.
AI is more like the early web. There is definite value that people can see, but no one really knows how to monetize beyond the incredibly obvious 'sell people access to it', so everyone is throwing spaghetti at the wall waiting for it to stick. When someone gets it to stick, there will be a giant amount of money coming at them, but until then there will be a ton of people with sauce all over their faces looking like idiots.
llbbdd12 hours ago
Upvoted to save you from the negatives because I too am tired of seeing the comparison to blockchain. I'm not sure where it even comes from other than just being another recent hype train people remember, but blockchain settled into a relatively tiny niche. The most basic deployment of LLMs / AI by comparison is instantly, obviously more useful than that.
sleepybrett9 hours ago
As soon as it starts returning to me factual, confirm-able answers consistently. Then I'll use it. I just had to fix something a co-worker fucked up by asking ai how to do it. The responses are so confidently wrong it's like watching Kash Patel tell me that Jeffrey Epstein killed himself.
cheema339 hours ago
> As soon as it starts returning to me factual, confirm-able answers consistently. Then I'll use it.
Humans don't behave this way. Yet, we still employ humans. AI is unreliable. We all agree. But that does not make it useless.
lmm7 hours ago
Ok, how about: Once AI is less overconfident than a median teammate, it may be worth something. It's not there yet.
Eisenstein5 hours ago
I agree. Overconfidence and sycophancy is the real problem. This should be the focus of development energy. The models are already capable; now they need to be reliable.
charcircuit15 hours ago
People are biased to using tools they are familiar with. The idea that if a tool was useful people would use it simply false. In order to avoid being disrupted, extra effort needs to be made to get people to learn new tools.
DeepYogurt9 hours ago
You're presupposing utility.
soraminazuki10 hours ago
From the CEO's article referenced in that post [1]:
> the rise of AI in software development signals the need for computer science education to be reinvented as well.
> Teaching in a way that evaluates rote syntax or memorization of APIs is becoming obsolete
He thinks computer science is about memorizing syntax and APIs. No wonder he's telling developers to embrace AI or quit their careers if he believes the entire field is that shallow. Not the best person to take advice from.
It's also hilarious how he downplays fundamental flaws of LLMs as something AI zealots, the truly smart people, can overcome by producing so much AI slop that they turn from skeptics into ...drumroll... AI strategists. lol
badosu14 hours ago
Reminder that Github _still_ does not support IPv6: https://github.com/orgs/community/discussions/10539
sethops113 hours ago
I contacted GitHub support about this and they assured me they understand it's a priority and are working on it. Three years ago.
cozzyd5 hours ago
Surely their LLM can work this out
maerF0x016 hours ago
cheaper than layoffs.
kunley15 hours ago
[flagged]
xyse5316 hours ago
Devs leaving can often be a stability boost :)
stevefolta14 hours ago
But if that's what they want, they may be driving out the exact wrong subset of their devs.
doubled11216 hours ago
Right up until it isn't.
john01dav15 hours ago
I use gitea on a server in my basement because I don't trust these hosted solutions to not use my code for LLM training or who knows what else.
zaphar15 hours ago
Me too. I have it mirroring stuff from github too for occasions just like this.
eats_indigo15 hours ago
Given Github's critical role in software engineering delivery, their SLA commitments are really quite poor, perhaps unacceptable.
harrison_clarke15 hours ago
luckily, git itself works pretty well when there's an outage
sucks for people that use issues/PRs for coordination and had a planning meeting scheduled, though
graemep15 hours ago
It is critical for those who choose to use it.
If you deliberately decide to use a system that introduces a single point of failure into a decentralised system, you have to live with the consequences.
From their point of view, unless they start losing paying users over this, they have no incentive to improve. I assume customers are happy with the SLA, otherwise why use Github?
yunwal12 hours ago
Network effects are quite strong
hnthrow9034876512 hours ago
I miss the days where downtime would be like half a day or more and you could use it as an excuse to go home or do something else.
Weirdly people were less angry about it back then than we seem to be today.
tyre7 hours ago
It was like a snow day! So fun.
vouaobrasil11 hours ago
That's because people can't handle speed. With a natural delay, they could cool down or at least become more detached. Society needs natural points where people are forced to detach from what they do. That's one reason why AI and high-speed communications are so dangerous: they accelerate what we do too quickly to remain balanced. (And I am speaking in general here, of course there will be a minority who can handle it.)
antihero16 hours ago
Guess it's time to embrace AI.
dorian-graph16 hours ago
sleepydog15 hours ago
... or get out.
dang14 hours ago
(Presumably?) related ongoing thread:
Why is GitHub UI getting slower? - https://news.ycombinator.com/item?id=44799861 - Aug 2025 (76 comments)
pelagicAustral16 hours ago
Good thing I always commit directly to the main branch.
mattwad16 hours ago
this is broken too!
mmastrac16 hours ago
Good thing we're using a shared Samba drive and editing files directly without locks!
tetha15 hours ago
We have post-its with file names on a wall in the office. You take one down if you edit the file, and put it back up when you're done. Easy.
Though I wish I was entirely kidding. ~12 years ago or so we did that if one of two parallel development teams had to modify a message of the network protocol to avoid incompatibilities and merge problems.
Mind you, these were SVN merges. I can't even verbalize my feelings about SVN merges but by a mixture of laughing and groaning in pain, like if you stubbed your toe in a painful, but entirely funny way.
xorcist13 hours ago
What is this eternal meme about merges in svn being harder than in other tools? Git used literally the same merge algorithm, even if that has changed a bit since then, and merge conflicts are not something a tool can't just magically make disappear. If you want concurrent edits (the c in cvs), conflicts come in the same package. Various algortihms can supply their own dose of magic, but they're more similar than different (minus a few special cases such as rerere in git).
tetha13 hours ago
My interpretation within that company: You know this new idea of "If it's painful, do it more"? People in that company didn't do that in the SVN days or earlier, because merges were painful. Thus, merges filled a sprint if they had to be done. This made sense if you came from CSV or nothing, tbh.
Git in turn made branches easier, causing merges to be more prevalent and developers overall learned to merge more, merge more often.
spicybright14 hours ago
Keeping it when tech can't keep up is genuinely a good hack for any kind of engineering. Physical lock out tag out on industrial machines for instance. Passing paper notes/wooden blocks in air traffic control towers to see who's responsible for what even if computers go down.
SparkyMcUnicorn16 hours ago
Project_v2_final3 is looking good, but remember to grab the new actionscript files out of Project_v2_final4 as well.
rwmj16 hours ago
You joke, but when I was doing my start-up we made good money on the side from monitoring websites to detect when the designers had pushed regressions to the live site. We would keep track of change requests that were filed and resolved, then scripts would monitor the sites to see if any earlier changes had been backed out. (Getting the designers to use version control was considered to be in the "too hard" bucket. This was back in the mid 2000s.)
yieldcrv16 hours ago
This is how to collect low to mid 5 figures a year doing bug bounties too
Its all about the regressions, not finding anything novel
d-lisp15 hours ago
If this isn't cosplay I'd be glad to know how you do so.
hnuser12345616 hours ago
Also the foo_bar method from v1 worked better so pull that back in
taude16 hours ago
So glad we never bothered to migrate from Visual Source Safe
davey4801615 hours ago
That's a single point of failure. If you email code changes around and use an email client that copies everything offline, then the history of your code base is distributed across all of your developers' laptops.
vehemenz15 hours ago
Make sure everyone has caching disabled, for maximum effect
ZiiS16 hours ago
Still better than CVS then /s
jaredsohn16 hours ago
Good thing we just SSH into production and make the changes live.
rwmj16 hours ago
You're using Ansible?
hdgvhicv13 hours ago
Do it manual you can screw up one server at a time
Run ansible and you can screw it all up
redserk16 hours ago
Subtle Elixir/Erlang advocacy here.
gloxkiqcza16 hours ago
Vibe coding nonetheless #gofastandbreakthings
phendrenad215 hours ago
rsync is all you need ;)
jaredsohn13 hours ago
nah - ftp
or run vi from ssh
escapecharacter16 hours ago
They must mean their local main branch.
RonanSoleste16 hours ago
No the remote one. No need for a local branch.
ItsABytecode16 hours ago
I didn’t think the code I just merged was that bad
clysm15 hours ago
Why is this linking to a merged PR, or a PR at all, and not a status page?
organsnyder15 hours ago
It must be back up!
lrvick15 hours ago
Does not impact me, because my team and I self-host Forgejo for all our work.
People seem to forget Git was meant to be decentralized.
redrove15 hours ago
Yes, but you may work with other people, other organizations, or at least depend on open source code that's hosted on GitHub.
I agree with the sentiment though.
lrvick15 hours ago
Do work in and rely on self hosted forks so you are not blocked, and upstream when upstream code submissions become possible again.
njovin16 hours ago
Props to Github for having an accurate status page. AWS and Google should take note.
ietktnz16 hours ago
Status page says "Incident with Pull Requests". Pull requests status is listed as "Normal". Status text says issue with degraded performance for Webhooks and Issues, does not mention Pull Requests.
I would give that a 5/10 accuracy at best!
ericyan16 hours ago
The status page has been updated. PR and webhook statused red and now listed as "Incident".
(Disclosure: GitHub employee)
samgranieri16 hours ago
they've updated the page since then. Take a look
sleepybrett9 hours ago
As someone who is partially responsible for supporting github at a very large organization, no it isn't. At least not until the incident is at least 30m old if ever.
politelemon16 hours ago
Does GitHub development happen on GitHub? And if the fix for broken pull requests requires a pull request would they have a way to review it...
gimenete15 hours ago
I worked there for 3 years and yes GitHub development happens on github.com. Of course there’s ways to deploy and rollback changes while the site is down but that’s very unusual. The typical flow happens in github.com and uses the regular primitives everybody uses: prs, ci checks, etc.
The pipeline for deploying the monolith doesn’t happen in GitHub Actions though but in a service based in jenkins.
Fun fact: playbooks for incidents used to be hosted in GitHub too but we moved them after an incident that made impossible to access them while it lasted.
coryrc15 hours ago
> that made impossible to access them
Couldn't they just be checked out by cron on any number of local machines hosting Apache?
gimenete14 hours ago
I don't remember clearly where we moved them. It was probably to something owned by Google (because GitHub uses Google Workspaces) or Microsoft (for obvious reasons).
[deleted]15 hours agocollapsed
naikrovek15 hours ago
if GitHub Enterprise Server is anything to go by, they build (almost) everything for containers, and the entire site is hosted by containers managed by Nomad. So there are probably lots of older images around that they can fall back on if the latest image of any container causes problems.
How they would deploy the older container, I don't know.
A lot of this is guesswork, I don't work for them or anything. And I know that GHES in the way that my employer manages it is very unlike the way that GitHub host github.com, so everything i've assumed could be wrong.
axelpacheco16 hours ago
Give your best estimate on how much dollar value of creation is wasted every hour GitHub PRs are down
bob102916 hours ago
I estimate that on some days an outage like this could ultimately save some businesses money.
There's a lot of cowboy development going on out there. Why not take this opportunity to talk to your customers for a bit? Make sure you're still building the right things.
henryfjordan15 hours ago
At a startup, sure.
At any decently-sized org, the developers are not allowed to talk to customers on their own accord.
bob102915 hours ago
I've never worked somewhere I couldn't email a customer as long as the team was CC'd. This is a bit of a circular problem because if you don't get exposed to the customer in some capacity you'll never get good at working with them.
If the business is afraid to let you email the customer, you might need to work on your communications skills and go through some intentional demonstration efforts. For example, "Good morning <boss>, here's a draft of what I think we should send <CTO's name @ customer> regarding their feedback on the last build.".
That's literally all it takes to get into the game. Don't ask for permission to write the draft because then your managers will think it's gonna be this big ordeal and they'll definitely say no.
henryfjordan15 hours ago
At a B2B, I might agree with you.
At a B2C, I would not email a customer directly without sign-off. We have marketing teams, research teams, comms, customer support, etc. I would be stepping on so many toes, and risking brand reputation, if I were to interact with our customers.
Hackbraten15 hours ago
> There's a lot of cowboy development going on out there
This has been the case before VCSes existed.
jennyholzer16 hours ago
$2000
StarlaAtNight16 hours ago
One MILLION dollars puts pinky to corner of mouth
noreplydev16 hours ago
https://www.githubstatus.com/ "git operations: degraded", my git operations are degraded by default
Imustaskforhelp16 hours ago
This is why I recommend decentralized protocols like radical or I guess I hope that tangled.sh could fix this stuff too.
I am not sure about tangled.sh, I might ask them in their discord about this now y'know.
lionkor16 hours ago
Git is a decentralized protocol, it's just incomplete IMO
pmontra16 hours ago
There is git format-patch to create a diff and git send-email [2] to mail it to another developer and git-am [3] to apply the patches from a mailbox.
The Linux kernel developers have been using that workflow for a lot of time. Maybe still now.
[1] https://git-scm.com/docs/git-format-patch
lucasoshiro15 hours ago
> The Linux kernel developers have been using that workflow for a lot of time
Yes, they do. Git itself is also developed that way.
Btw, you don't need to use format + send-email, send-email calls format-patch under the hood
rightbyte16 hours ago
Communication layer agnostic text files is a killer feature of git. What MS is doing with Github is typical EEE.
ashwinsundar11 hours ago
Git and GitHub are not the same thing. git repos can live independently of GitHub
What features do you feel like git is missing?
RGBCube14 hours ago
Radicle.xyz fixes this with COBs (Collaborative Objects). They're stored inside your git repo as normal objects, and benefit from its p2p mechanism as well. It's the true sovereign forge.
2OEH8eoCRo016 hours ago
Git has a protocol called email.
immibis15 hours ago
Indeed push/pull wasn't even the original design intention of Git. It was a tool for one person to manage trees of emailed patch files.
lucasoshiro15 hours ago
> it's just incomplete
Why?
nwatson16 hours ago
Set up a second remote on Bitbucket or other and synchronize through that. Pipelined, etc might be missing but at least development can proceed.
[deleted]16 hours agocollapsed
KoboldAdvocate16 hours ago
Not a good look when they're heavily pushing AI agents.
phendrenad215 hours ago
It used to take a whole team of developers to take down production, now, one programmer with a fleet of agents can do it in 1/10th the time!
drumdance15 hours ago
At first I thought this mean that the absolute count of pull requests was trending down and this could be a new BLS data point.
thimabi16 hours ago
I’ll be waiting expectantly for the post mortem of this. How ironic would it be if this issue was caused by a pull request itself?
maerF0x016 hours ago
weird... this is redirecting me to `Privacy Statement Updates September 2022 #582`
crazysim16 hours ago
It was probably just an example.
[deleted]16 hours agocollapsed
darth_avocado16 hours ago
kvemkon16 hours ago
Thread on HN: https://news.ycombinator.com/item?id=44799435
dang14 hours ago
Since the current submission has the clearer URL, we'll merge the comments hither. Thanks!
[deleted]16 hours agocollapsed
greenie_beans16 hours ago
don't wanna be spreading fake news, but i wonder if this is related to a cloudflare issue? i've been unable to login to cloudflare for the past ~30 minutes. and: https://www.cloudflarestatus.com/
jdthedisciple16 hours ago
This is strange: I was just having issues with Pull Requests on BitBucket too. Coincidence, actually?
aduwah11 hours ago
It's all a central svn in AWS
tzury16 hours ago
(+WebHooks) (+Issues)
alberth15 hours ago
Email-based workflow, does have a few benefits like mitigation from this issue.
csh60216 hours ago
Seems total downtime was from 15:51 to 16:14 UTC
SwiftyBug16 hours ago
Right in the middle of a huge rebase. Great!
AdventureMouse16 hours ago
It’s never a good time for GitHub to be down!
[deleted]16 hours agocollapsed
sitzkrieg15 hours ago
how many more years of this before people realize its actually not good at all?
udev409615 hours ago
https://radicle.xyz is the future!
ath3nd15 hours ago
Wait, wasn't GitHub a company ran by the guy who just two days said that devs should either embrace AI or leave the field?
https://www.developer-tech.com/news/embrace-ai-or-leave-care...
Maybe his developers embraced AI a bit too much? Or maybe they left the field?
[deleted]16 hours agocollapsed
crinkly16 hours ago
No excuse. git-send-email out and stop slacking :)
MattGaiser16 hours ago
GitHub gives everyone an extra long lunch.
trashburger16 hours ago
Early EOD for me!
[deleted]16 hours agocollapsed
sidcool15 hours ago
It's up now.
hardworker0216 hours ago
Uh.. pub?
crinkly16 hours ago
Already in it. Was a premonition.
elmwoodfire316 hours ago
[dead]
mintaka515 hours ago
[dead]
mintaka516 hours ago
[dead]