How to Lose Stars on GitHub? | Hacker News Reader

How to Lose Stars on GitHub?

qovery.com

19 pointsmarkomunich49 comments

When you click the button to make a repo private, you first have to acknowledge that you will lose all of your stars among other things. Losing stars is literally the first bullet point. Then you have to type the repo name as acknowledgement before you can make private. PR stunt?

Make private:

Hide this repository from the public.

    You will permanently lose:
        All stars and watchers of this repository.
        All pages published from this repository.
    Dependency graph will remain enabled. Leaving them enabled grants us permission to perform read-only analysis on this repository.

This is useful.

Also of interest for those who care - you can contact GitHub support and they will remove the link to the repository you forked from.

This can be useful if you're actively developing a project that was abandoned, as it makes it so default PRs are against your master instead of against the origin repository.

Even worse than that - you have to go into the "danger zone" on GitHub, and then there's a big banner that says "Warning: Potentially destructive operation" and also the gates you mentioned.

They bypassed numerous sanity checks and then clicked the button that did exactly what it told them it would do, and now they're sad.

Do stars on GitHub _do_ anything? Usually I'm a bit put off by any kind of internet point begging, but I'm curious what the impact of losing them is. Is it mostly a signal of "I like this"?

> Is it mostly a signal of "I like this"?

It's a bookmark in theory (in 'Your stars'), but more or less just a 'like'.

Discarding self-validation social media-ing, stars xlate into discoverability and ranking algo positions for the starred and bookmarks for the starrer.

Granted whoever was doing the privating was acting in a hurry, but the modal you use to switch a GitHub repository to private says right on it:

    * You will permanently lose:
     * All stars and watchers of this repository.

along with a yellow banner at the top of the modal saying:

    Warning: this is a potentially destructive action.

This shouldn't have come as a surprise.

The "potentially" wording you see in those messages is a bit weird. It should just say it's destructive, and those who know about what it does will still do it.

Ah, who am I kidding? Nobody reads these things.

I suppose it's technically correct to say "potentially". You won't be losing any stars if you don't have any to begin with. Thus there's no destruction.

Yeah, and if you have a local repo copy with all the branches pulled, you won't lose data, either.

Still, technically correct is often the wrong kind of correct (but they would have made it private anyway).

> Our team leaked an API key in a Git commit during maintenance and was immediately alerted by GitGuardian. To revert that change and clean up the git history, Pierre decided to switch our repository from public to private until our team fixed it.

I hope they still invalidated that key and got a new one, because I don't think simply git reset and force pushing to overwrite a commit you already pushed to a public repository is sufficient to make sure someone didn't already capture it.

"I hope they still invalidated that key and got a new one, because I don't think simply git reset and force pushing to overwrite a commit you already pushed to a public repository is sufficient to make sure someone didn't already capture it."

-I totally agree you.

In fact, you should have an "ohshit.bat" command ready to go that contacts everything and invalidates/replaces the API keys.

And like your backups and your SSL certificates, you should actually run it regularly.

Invalidating the key should've been their first move and then stopping to think their second. Rushing around without a plan invariably leads to damage and errors.

"I am sure Github can do something about that, but they don't want to bother. Can you share this story with your friends working at Github?"

Interesting they know more about github's internal architecture than github themselves

Kind of ironic that a company built around a tool that enables easy reversion doesn't appear to have the ability to revert a change, don't you think?

> ... we don't track stars on our end...

This seems false, clearly they're stored in their database. This seems like a response from someone who doesn't exactly know what he's talking about. Perhaps they are deleted but there is certainly a backup someone could find the data in.

Keep pushing.

Thats a lot of work for GitHub: 1) Find a backup from before this change was made. 2) Restore backup on new db instance separate from prod. 3) Export star gazers list for this one repo to CSV or something. 4) Destroy instance restored from backup. 5) Execute admin script with CSV against production database to insert lost stargazers.

This gets even more complicated if GitHub has more than one central database, which I’d assume they have something like sharded mysql.

Considering that they made the change acknowledging that it would destroy their stargazer list in the confirmation dialog, it’s unfair for them to expect any help from Github’s support recovering that list.

Hmm. that's aweful list of things to revert back. Sure it seems difficult to revert back in production systems.

This reminds me a lot of YouTuber DarksydePhil. His videos would appear in peoples' recommendations because they gained so many views. After he unlisted some of his more popular videos, YouTube stopped counting them towards his overall influence, resulting in them promoting his content much less. The series Down The Rabbit Hole explains it here for anyone interested: https://youtu.be/So7wLuuDiHA?t=1422

I don't understand this kind of self-sabotaging behavior, like deleting "old" videos that people may rightly want to watch again and perpetuating bit rot.

I think you should update the title of the blog to be: We lost 3800 stars on Github in 5 clicks, 1 of which confirmed losing all stars

Why do you even notice, or keep track? Is there a way to disable visibility of stars?

Vanity, stop it.

Really confused by Github saying they don't track stars. If they don't then how does it work? Surely that data is somewhere.

I think they have stars counter table which they refresh or reset when a repo goes from public to private. But, the real question is, why not Github alert you by saying that the switch will make you lose all your hard-earned stars?

I'm assuming that they have a relation user <-> repo of repos that the user has starred. If the user in question doesn't have access to the repo, the entry should be deleted.

I was thinking the same thing. The star count is not just a number in their database. It is a count based on the underlying user data.

If Github deleted the user-to-starred-repo data then it'd be awfully difficult to restore the previous stars. They'd have to know which users had starred the repo previously and restore each of those relations.

Do they have backup data? Probably, but that's in the case of an emergency, not because of something like this.

>why not Github alert you by saying that the switch will make you lose all your hard-earned stars?

It is the first bullet point when you are submitting acknowledgement that you want to switch your repo to private.

Thanks for informing this. I just came to know this first time.

They 100% do alert you. This is an unfortunate situation, but all of these things are presented to you before you make the switch.

Since they keep track of who starred what, that means each star is a row. Does that mean they actually delete these rows? Why not just keep the rows, perhaps with a flag or join to filter the repo out of the API.

your point is quite informative!

In the modal for changing the visibility of a repo, when switching it from public to private, it says:

> You will permanently lose: All stars and watchers of this repository.

---

When the repository goes private, GitHub doesn't retain stars because they would be invalid; you can't star a repo you can't see, so those records would be meaningless. It could store them and "replace" them should the repo go public again, but then the repo could be very different from what the user starred in the first place.

They probably mean that they don't track _history_ of stars. The database is probably very simple and tracks only the current number of stars.

How else would this work though? https://github.com/bytebase/star-history

Looks like they figure it out by looking at the stargazers

> lost all the stars and forks from our repository

Does this mean that if I fork repo foo that if foo goes private my fork disappears?? I've never considered that case. Guess I'd better clone all my forks to gitlab or something.

I'm pretty sure that wouldn't happen as we would have heard of it by now (like if someone maintains a fork for years, then suddenly their repo vanishes because the parent went private), but that would be interesting to check what exactly happens. Maybe the text "forked from x" is simply removed from the children repositories.

This was not one error, there were multiple errors, including leaking the API key, and serious issues with how they make changes without proper team communication.

Well, a GitHub star is (theoretically ;) a bookmark. So it doesn't make sense to have stars that link to a private repo.

What defines a Github star is just a bookmark(therortically) ? Can you support this point with sufficient evidence? I have defined what factors will make it eligible for a star in Github. See my older comment.

publicity stunt

right? I don't see how the number of stars is anything other than a vanity metric

" I don't see how the number of stars is anything other than a vanity metric"

No, you can't say like that. It actually describes the usefulness and impact of github project. Who will come, check out the repo and star without estimating its usefulness, issues count, contributor count or code commit frequency and its impact on public websites and usefulness for the web? all these factors project that the project is having some "useful" rather than some sort of "vanity".

Lots of people, given its the closest Github has to a "bookmark" feature.

Extremely sad to hear this! My immediate upvote for you on Github. Upvoted! Hope dev. community won't let you down. You are sure to get more than 3500 stars; it reflects your hard-work in qovery engine & dedication to ease of use in cloud deployments. I'm also looking for some stars in my competing analytics library timeonsite JS. Kindly star this too, dev. community: https://github.com/saleemkce/timeonsite

guys, I'm really disappointed. I haven't said anything wrong. Just a "consolation message" for the loser with whom I don't have any relation but see my post is intentionally down-voted by haters.

I'd guess that people wouldn't mind the "consolation message", but are objecting to the blatant self-promotion that accompanies it. We don't read HN comments because we want yet more ads; the internet has more than enough of that garbage already.

Thanks for clarifying me.

> Kindly star this too, dev. community

Out of curiosity, what does the star provide to you? Do you gain something if people who are not genuinely interested star the project?

Reply on news.ycombinator.com