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.
> 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 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.
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.
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.
" 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".
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.
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"?
Discarding self-validation social media-ing, stars xlate into discoverability and ranking algo positions for the starred and bookmarks for the starrer.
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.
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.
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.
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.
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 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.
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.
> 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.
52 comments
[ 5.0 ms ] story [ 106 ms ] threadOut of curiosity, what does the star provide to you? Do you gain something if people who are not genuinely interested star the project?
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.
And like your backups and your SSL certificates, you should actually run it regularly.
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.
It is the first bullet point when you are submitting acknowledgement that you want to switch your repo to private.
> 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.
Looks like they figure it out by looking at the stargazers
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".
Make private:
Hide this repository from the public.
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.
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"?
It's a bookmark in theory (in 'Your stars'), but more or less just a 'like'.
Ah, who am I kidding? Nobody reads these things.
Still, technically correct is often the wrong kind of correct (but they would have made it private anyway).
Interesting they know more about github's internal architecture than github themselves
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 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.
Vanity, stop it.
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.