Let's assume that the stars don't go away when the repo is made private. There are a couple of options:

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

- 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.

- The users can see all their stars, but the private ones lead to a 404, which would be perplexing for a greater number of people than the current behavior.

- 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.

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

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.

I think this is getting at the more robust solution.

When youtube videos are taken down or made private, they are not deleted necessarily from my playlists. There's simply an indicator that they video is 'no longer available'. I don't see why something similar can't be the behaviour for GitHub stars and watches?

You do lose the title, which is super annoying. "What did I used to have?" Super frustrating feeling.

Here's a list of your favourite songs, but two are missing, have fun figuring out which two it is!

I recently discovered a neat trick that if you Google the url for the private video (you still have this in your list), you're likely to find the title of the video, therefore allowing you to at least figure out what it was and seek out a new video.

This works about half the time. It's better than nothing, but not great.

Thank You! I needed this all my life!

Agreed. This just screams bad UX on a corner case.

1) probably not the desired experience

2) probably part of the currently required setup on their database side (triggers)

Features tend to evolve evolutionarily and certain data patterns are hard to invent around for security/privacy constraints. So err on the side of deleting rather than potential privacy/security bug.

Definitely fixable with some decent investigation, coding, etc. - but hard to prioritize.

Totally agree - cascade delete is such a nice thing - until it is not.

Technically you want to delete dependent stuff, but in this case this seems like overstepping on development side.

But couldn't the same be achieved without taking it private?

You can do that without the “making it private and public again” part anyway.

Yeah, that's a risk. They could mitigate it by allowing you to revert all branches/tags back to the pre-private state, but we're getting more and more complicated here.

Yeah but it's not like stars are seen as some amazing endorsement on the part of the individual starring. It's more like a favorites list if anything

stars absolutely are seen as an endorsement. I'm guilty of that for sure, and I've been in a ton of conversations about adopting some thing and the "number of stars" is often a consideration unless it's a project like React or Vue, etc.

Would you really not look at two repos that do the same thing, with similar ages and recent commits but one has zero stars and the other has hundreds, and not at least initially trust the latter more?