How to Lose Stars on GitHub?(qovery.com)
qovery.com
How to Lose Stars on GitHub?
https://www.qovery.com/blog/we-lost-3800-stars-on-github-in-1-click/
52 コメント
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"?
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"?
Discarding self-validation social media-ing, stars xlate into discoverability and ranking algo positions for the starred and bookmarks for the starrer.
> 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'.
It's a bookmark in theory (in 'Your stars'), but more or less just a 'like'.
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.
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.
[deleted]
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.
Warning: this is a potentially destructive action.
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.
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).
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.
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 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.
-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.
And like your backups and your SSL certificates, you should actually run it regularly.
"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
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.
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.
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.
[deleted]
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.
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?
They 100% do alert you. This is an unfortunate situation, but all of these things are presented to you before you make the switch.
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.
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.
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.
> 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.
[deleted]
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
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.
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".
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
> 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?
Out of curiosity, what does the star provide to you? Do you gain something if people who are not genuinely interested star the project?
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.
Make private:
Hide this repository from the public.