star-history VS nix-helpers

That’s a great project you pulled off. From the time I starred it (10-12h ago I think), and upon re-checking this post, you gained 500+ stars lol.

Visualized in a chart with star-history: https://star-history.com/#nilsherzig/LLocalSearch

You can actively see a fresh "hype curve" in the transformer-debugger repo that was posted a couple days ago (https://github.com/openai/transformer-debugger) (star history https://star-history.com/#openai/transformer-debugger&Date).

Regardless of the repo's stars or how valuable it really is, at the time I saw it posted to HN, it had 1.6k stars/16 hours. What channel are people listening to to star it so quickly. I'm not implying any nefariousness, mind you, I'm only wondering where all the stargazers were referred from so fast and in such volume.

I’ve been releasing open-source projects for years now, and I’ve always wanted to see how fast my Github repo is growing compared to other successful repositories on https://star-history.com/. The problem is that on Star History, I’m unable to zoom into the graph, so a new repo that has 1,000 stars cannot be compared with a big repo that has 50,000 because you can’t see how the bigger repo does in its beginning. So, I asked GPT Pilot to build this functionality. It scrapes Github repos for stargazers, saves them into the database, plots them on a graph, and enables the graph to be zoomed in and out.

i'm a one man shop in montana, competing w/ Google, Vercel & Facebook for dev mindshare

if i did what everyone else does you never would have heard of htmx

https://star-history.com/#bigskysoftware/htmx&Date

also: https://star-history.com/#bigskysoftware/htmx&facebook/react...

Similar to http://star-history.com for GitHub repos, http://like-history.ai is a tool to help generate the like history of projects on HuggingFace.co

More details: https://twitter.com/Tim_Qian/status/1730245069259575485

yeah, he was the one that really started the madness:

https://star-history.com/#bigskysoftware/htmx&bigskysoftware...

his video posted on july 7th

Github star history graph of the batch:

https://star-history.com/#trpc/trpc&termux/termux-app&respon...

Yes, to get Nixpkgs it's much faster to use `fetchTarball`.

You're right that `builtins.fetchTarball` is faster than `builtins.fetchGit` (due to the ridiculous amount of commits in the Nixpkgs repo). I like to keep such definitions in a single, company-wide/project-agnostic git repo (what the Nix Pills series calls the "repository pattern"), and have individual projects import them via `builtins.fetchGit`.

Many years ago we didn't have `builtins.fetchGit`, so had to use the 'fetchgit' function from Nixpkgs instead. That created a chicken-and-egg situation if we wanted to take the Nixpkgs version from some other git repo; hence needing to "bootstrap" via `(import { config = {}; }).fetchgit`, and cross our fingers that `NIX_PATH` wasn't set to some crazy value (which, of course, I would inevitably do... https://github.com/Warbo/haskell-te/blob/24475a229908caa3447... )

Note that we need `config = {};` when importing Nixpkgs to avoid an impurity which tries to read files in $HOME. More recent versions of Nixpkgs also need `overlays = [];` to avoid another impurity (looks like this changed at Nixpkgs 17.03, according to https://github.com/Warbo/nix-helpers/blob/master/nixpkgs.nix )

Where nixpkgs2105 is a pinned revision of the Nixpkgs repo, defined in another overlay. My current Nix config has pinned Nixpkgs versions going back to 2016. For example, here's a bunch of such overrides:

https://github.com/Warbo/nix-config/blob/master/overrides/fi...

At the moment I'm using niv to manage the pinned Nixpkgs versions (the 'repoXXXX' entries):

https://github.com/Warbo/nix-helpers/blob/master/nix/sources...