Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Agreed, and I'm genuinely surprised that so many on HN are angry at GitHub when they already made it so hard to do this. The author explicitly mentions they were on autopilot - it would take a significantly more challenging barrier for them to not do the exact same thing no matter how many prompts GitHub put there. It does make sense for it to be more reversible, but I can also understand why GitHub doesn't want to put in the effort: this is a once in a year kind of incident and the resources required wouldn't be worth it compared to signal boosting, like they did on twitter. I, for one, would be extremely pissed if GitHub made it harder for me to do routine actions because there's a possibility of data loss. I signed up for that when I typed the repository name in.


I intentionally did this very recently for a whole bunch of old repos (mainly because a Github bot decided to start emailing me weekly about vulnerabilities in stuff that has been untouched for nearly a decade) and was mildly annoyed at how inconvenient it was to make them private. I would have said the warnings are unnecessary overkill.

It's quite amusing to read this so soon after.


Same here - not too long ago I had to take a bunch of repositories private, and while I appreciated the prompt (I've dealt with destructive actions that have even less of a barrier before, and that sucks) it still was annoying to do that again and again.


The point the author makes is not that it should be more tedious to make private: they in fact suggest making it as tedious as it is only when you are on a new, non-massively-starred repository. Right now it is only tedious and not sufficiently alarming, is what people are saying.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: