Your last option sounds appealing to me here. Yes it does mean that you can never really make the name of your repo fully private after it's been started, but the name isn't really what's important most of the time.

And there's always the potential to add a other toggle when privating a repo that lets you force-remove all stars.

Perhaps 1-2 weeks of warning before a full delete of stars would be desirable for any repo with over 1k stars.

Sorta like most social media apps when you want to delete your account. It doesn't delete it fully until a month later

> The users can still see all their stars and find the private repo, which makes it not private.

Why seeing a start you made for a previously public repository makes it not private? People remember things too, there's also the webarchive. You should be able to unstar it or keep your star, the only difference is that you don't know if the repository still exists or not.

> the only difference is that you don't know if the repository still exists or not.

If an admin were to private->delete, then all the stars referencing the report would stay and thus the reference to the repo would still be there, on GitHub's servers. There's a difference between GitHub storing things forever and third parties on the internet being a forever archive of visible pages.

But that's an easy fix. If they delete the repo, delete the stars. If they make it private, indicate it is now private in some way.

That's information disclosure; nothing about the repo after it's privated should be known, including name changes and deletion.

It’s unclear to me what the attack vector is for that disclosure.

It was known and there are many sites scraping GH for metadata that will have it anyway

Not whether or not a repo exists after it's set private.

This information is useless. It leaks nothing but name and existence of something once public (that vanished from public view). Most importantly it's not confidential or critical in any way

The repo could lead to 404 to everyone, but if someone had starred it they would get a 403. They would be able to see all their stars but not access certain repos because they were made private. Probably less surprising then some of their stars disappearing. They would at least know what happened and it’s not like wouldn’t know the repo was public at some point anyway. Additionally, there could be another button to clear stars and watchers, if the owner of the repo really wants to.

>I think the current behaviour is better than all of these options.

Current behavior is destructive.

>- All private repos that have been public at least once lead to a "this repo is now private" message, that would in practice allow anyone to make an index of all the private repos that were public at least once. And it would also allow anyone to know when a private repo that was private at least once is deleted.

This is a much better option.

Twitter has this kind of problem with likes (or maybe they fixed this since I haven't been on there in a while).

When someone deactivates their account, you can see that you have X additional likes, but you can't access them. If that user reactivates their account, those likes suddenly show back up.

This could be a privacy issue if you've decided to remove likes for a certain categories of posts for whatever reason.

For GitHub, a couple other options I can think of would be to 1. show stars for private repos but only for the purpose of unstarring or 2. hide stars when a repo goes private and then give users an option to re-enable their star if a repo goes back to public. But these options are relatively complex, and I can see why GitHub would go with deletion.

> The users can't see all their stars, they can only see their stars for the public repos. There's no way to find or unstar a private repo that you starred while it was public. This would lead to the situation that if you unstar everything and make sure you have zero stars, you could wake up the next week with 1 starred repos, and then with 3 starred repos, because some repos went public again.

Sounds fine and expected to me.