To point out what might be obvious: this doesn't transfer _just_ the stars. It simply swaps two repos, which means the issue tracker, pull requests, watchers, forks, projects, etc., also get transferred with the stars.
It's not possible to transfer just the stars while maintaining all the things that you can't directly control.
I did something similar when I decided to change my github username without changing all the import paths of Go packages I had. I changed the username, made an organization with the same name as my previous username, then moved all my repos to the organization. So the URLs of all the repos stayed unchanged. [1]
When you rename yourself on GitHub, their Help says they put in redirects for all of your repositories (that last until such time as someone else claims your old name and creates a new repository with the same name as one of your old repositories, as this new repository supersedes the redirect). So squatting on your old name is a good idea to protect the repository URLs, but actually transferring your repositories to the squatted name seems unnecessary.
Yeah, I was aware of the redirects, they're very helpful! It would've been okay to rely on redirects on a temporary basis if my long-term plan was to move everything to the new username. But I wanted the repos to keep their old URL permanently, so that's why I moved them.
I'm no git master and after searching around a bit I wasn't able to find a clear answer to this so I'm hoping someone can enlighten me:
Say I accidentally push some private info and overwrite the commit with a force push. The commit history doesn't show the mistake commit at all, but is it actually still accessible through reflog?
I'm pretty sure I've done this with some of my smaller projects so now I'm concerned that some of my passwords/keys are actually floating around somewhere. I read some info about reflog automatically pruning, is it likely that this is the case for my projects and I have nothing to worry about?
Afaik (I'm no security expert), as soon as you pushed them to a public repo you should change them all regardless of force pushing, because there's no way to take it back. Folks do trawl github for passwords and secrets.
Yep you can recover from force pushes on the remote - ie: you can reset it. You have to do it using GitHub’s web API but it is possible (and handy!)
As GitHub themselves say:
> Warning: Once you have pushed a commit to GitHub, you should consider any data it contains to be compromised. If you committed a password, change it! If you committed a key, generate a new one [0]
Github might have pruning, but you can't rely on it, since their Git management system is quite custom.
That said, if the request for the Events (as shown in the previous link) doesn't show the problematic commit - or a commit that extends it -, I don't think anyone could fetch it without previously knowing the ID, and if they do, it's probably because they already have a local copy.
Huh, I didn't think that GitHub kept a reflog. Although, after thinking about it, I guess that they really need to since links to old commits continue working…
Makes me think of Theseus' ship. Change piece by piece out over time. Is it still the same repo people starred?
This feels a lot like what happens when a brand is sold. Is it really the same product?
Stars generally "work" because, I think, we assume repos converge to something. The older it is, the less likely changes are to be drastic. And maybe that's true. But it clearly doesn't have to be.
Of course we shouldn't rely on star count as any sort of quick and dirty metric of quality... But I think many of us do.
> This feels a lot like what happens when a brand is sold. Is it really the same product?
It is why brands are sold. Someone buying a trusted brand wants to give their product starting levels of trust that it doesn't deserve. It's an effective way of cheating customers.
> It is why brands are sold. Someone buying a trusted brand wants to give their product starting levels of trust that it doesn't deserve. It's an effective way of cheating customers.
This seems excessively strong. Another way to view it is as a way of signalling intent (and proving skin in the game). Buying a brand is similar to those expensive and structurally pointless columns on old bank buildings: it proves the company has a put a lot of money on the line and doesn't intend to close up shop a week later.
I'm extemely skeptical about automated code quality scoring tools. Most of them focus on superficial metrics and completely miss the important stuff.
One of the most important metrics for project quality is how easy it is to implement new features. Good code is easy to extend and build on top. Developers who haven't worked on the project before should be able to easily jump in and start contributing good PRs. I don't think that this kind of scoring is something that can be automated... At least not for a long time.
Actually this is somewhat already done in a quite clever way by the product CodeScene by Empear (https://empear.com/). This tool looks at the history of files in a repo and detects a lot of things such as:
* Correlation between files (we always seem to change b.cs when we change a.cs)
* We have lost knowledge in the team, file a.cs was 85% created by developer X who has now quit.
* A certain file is often modified (indicating too many responsibilities, and thus "bad code").
I don't understand why this is a major deal, though. Allowing users to rename resources will always result in this kind of behavior, but I don't see how this could be a bug or a security hazard. Some similar things you can do:
+ Swap the handles and profile information on instagram — transferring Instagram followers
+ Swap the handles and profile information on twitter — transferring Twitter followers
+ Change the team name & URL on Slack — transferring Slack users
I agree, it's benign behaviour but developer and companies should be aware of the potential for misuse. Specially, stars in Github should not be considered a proxy for quality (I say this as the #2 most popular in star count in Japan).
It's a warm reminder for the future, since as the JS ecosystem keeps growing exponentially people will very likely start to search for metrics such as star count to know what to trust. This made quite a bit of noise recently for instance: https://hasvuepassedreactyet.surge.sh/
Author here, I created and alpha-launched https://comments.network/ a while back, but have since officially discontinued it and you should really not depend on it. I am considering open source-ing it, would that be interesting at all?
That's from the project owner's point of view but what about from the starrer's perspective?
I think most users use stars to denote endorsement/interest in a project. If you move my endorsement from projectA to projectB just because they merged, that assumes my endorsement/interest still applies.
That feels like a significant assumption that may not hold.
Exactly. I'd be 100% mad if I found out somebody shifted my public validation of their project to something entirely different. If I catch anybody doing this, they're dead to me. It's straight up fraud.
When should a project be considered something entirely different? See the other top level comment about Theseus' ship. Is Angular 2 different from Angular 1 for example? Would you be mad for them keeping your star? What about changing the direction of products? There _are_ valid cases and how much something changes is variable, so there is no clear line IMHO. It depends on each individual then to make their own judgement.
There are no clear lines anywhere in the world. Everything gets subtle upon close examination. Do you bring this fact up all the time? E.g., if your friends are going out to brunch, is their a long soliloquy about how the right term depends so much on exact time of day, history of the cuisine involved, and the specific foods people eat? That really maybe it's more lunch, or elevenses, or perhaps really more what's meant by morgenmete or perhaps petit-déjeuner? Perhaps best not to name it at all and let each person just see it as they see it.
Or do you instead only demand this level of philosophical nuance when, as here, it lets someone committing fraud off the hook?
Yup, I love discussing the limits of reality with my close friends. Obviously it's not a soliloquy if I'm discussing with my friends. The way different people see the same thing is f*ing interesting TBH, and one of the things I love the most of meeting new people.
And no, I don't think here I was commiting fraud. I purposefully did this to push and find out what other people think! But still staying on the side of what I consider ethic. (Honest) thanks for letting me know your opinion though.
Yes, but it would have been totally fair if they reused the same repo and maintained the old star count and everything, wouldn't it? They have maintained the brand after all.
My point is that it's difficult to define the limits of what people are endorsing. Some devs might endorse Angular 1 but not 2+, others might not care at all and just endorse Angular as a brand.
Of course there are situations where it's clear what is being endorsed, but not always.
Let's follow that to the extreme. An "endorsement star" can only really endorse the state of the project at the point-in-time when it was starred. Who knows what awful direction it might then take! You don't want your name attached to that! So the first time someone endorsement-stars a repo, it must become locked and un-push-able. Sorry folks, it's the only moral way.
If I'm looking for a library and I find two that do what I need, I generally go with the one with the higher star count because it signals a larger community and therefore it's more likely to get some bug fixes and improvements.
I don't think GitHub stars a reliable indicator of community size. They are often an indicator of how much effort someone has put into promoting the library on social media. Some people have starred thousands of repos that they only ever looked at once when they saw it on the front page of HN (I know, because I'm one of them).
A quick read of the source, tests, documentation, issues etc provide better information than counting stars in my experience.
> Some people have starred thousands of repos that they only ever looked at once when they saw it on the front page of HN (I know, because I'm one of them).
If you ever want to process and try and extract some value from those, I recommend this: https://astralapp.com/
I have very little interest in most of the differences in features, and the cost of switching is low in the future. So I'll just go with node-portfinder because it has more stars. ( I also notice the forks count is higher)
People have a marked preference for popular open source software.
* It's a signal of quality even if it isn't always the best signal, and developers won't necessarily allocate the time to investigate the quality of a package on a deep level.
* CYA: more stars indicates more popularity which indicates that your choice to use XYZ with 1000 stars is more defensible than the ABC package with 5.
* It suggests that the package will be maintained and improved rather than abandoned.
Sometimes it gives you some motivation or moral support to keep developing the software. I often see people open feature requests but don't even bother to give a star. If I put a repository out there that just works for me, I'm less motivated to spend extra time to accommodate features for other people. It's free software, there's no monetization like the view count on youtube, the least you can do to support the developer is give a star.
The more stars your project has, the more likely people and companies are going to use it.
Stars represent trust. When it comes to adoption of an open source project, trust is everything.
Which is terrible. Some people think because a github repo has a certain amount of stars they don't have to actually think or look at the actual code in that repo. I've seen devs frowning at github repositories because they "only had x stars" or recommending to "pick the library one with most github stars" as if that would be the best fit for your need.
I agree but very large companies go to extreme lengths to minimize risk in their code so number of stars makes sense from that perspective. What annoys me more is when statups refuse to use a library because it's not being used by any well known company. Then the open source library never gets any opportunity at all to prove itself; not even in a niche of small startups... It's like being homeless; nobody will give you a job no matter how good you are because you stink like failure.
This requires owning both repositories. The user puts a measure of "trust" in the owner whose repository he had starred already, so this seems more like a violation of that trust rather than an "exploit".
> While there are some shady services to buy fake Github stars, with this exploit a company could just pay someone and get their repository with real user stars.
Is that a thing?
That link to duckduckgo doesn't return anything relevant.
It's not possible to transfer just the stars while maintaining all the things that you can't directly control.
I did something similar when I decided to change my github username without changing all the import paths of Go packages I had. I changed the username, made an organization with the same name as my previous username, then moved all my repos to the organization. So the URLs of all the repos stayed unchanged. [1]
[1] https://twitter.com/dmitshur/status/1021266582834634752