Transferring GitHub stars
francisco.io
francisco.io
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]
So in this case even if you force push to the highly starred repo people could see that it had old commits (and restore to those on their local too).
Nice writeup on it: https://medium.com/git-tips/githubs-reflog-a9ff21ff765f
This has definitely saved my bacon when I've force pushed to a GH repo before and had to restore something.
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?
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.
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]
[0]: https://help.github.com/articles/removing-sensitive-data-fro...
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.
Which is a shame and shouldn't be happening, since newer authors (such as myself) are heavily disadvantaged from this method.
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.
* 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").
and so on.
More details: https://empear.com/blog/software-revolution-part1/
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.
+ 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
This is fairly widespread but benign behavior.
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/
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.
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.
Or do you instead only demand this level of philosophical nuance when, as here, it lets someone committing fraud off the hook?
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.
An example is https://github.com/indexzero/node-portfinder vs https://github.com/sindresorhus/get-port
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)
A quick read of the source, tests, documentation, issues etc provide better information than counting stars in my experience.
If you ever want to process and try and extract some value from those, I recommend this: https://astralapp.com/
"Five-hundred-and-one million, six-hundred-twenty-two thousand, seven-hundred-thirty-one. I am concerned with matters of consequence: I am accurate."
"And what do you do with these stars?"
"What do I do with them?"
"Yes."
"Nothing. I own them."
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.
Is that a thing?
That link to duckduckgo doesn't return anything relevant.