Lyn :coweat: :verifiedlesbian: (@fugi)

In the latest beta deployment, nixpkgs (>1.065.000 commits, about 1300 of which have been found to include AI stuff) doesn't get an F anymore but rather "only" an E, because 1300 commits is basically nothing against the >1.063.000 untainted commits. I like this direction a lot c:

@star do you actually check all of those now?

@fugi I have recused myself from the maintainer position of slopscore (other wonderful individuals cover it better than I ever did) and thus I haven't followed basically anything that has happened in the past month or so.

I implemented the 5000 limit, which is why I know it existed, but going through the codebase right now, it seems like it is gone. So, yeah, I think we actually do scan everything.

@fugi

commit 0a2f489e8a1893092d7dc0df47071354aae6e529

Author: ash lea <example@thisismyactual.email>

Date:   Tue Jul 7 08:40:00 2026 -0400



    remove --depth=5000 from git clone



    did some testing, --depth=5000 seems to require significantly more processing

    on the server side depending on the size of the repo (and possibly some

    software-specific caching characteristics). can sometimes result in time and

    bandwidth savings, but for extremely large repos like linux or nixpkgs is

    extremely slow and sometimes results in timeouts



    |name (codeberg/github)| clone+ls-tree (no --depth)    | clone+ls-tree (--depth=5000)  |

    |----------------------|-------------------------------|-------------------------------|

    |waterfox-android (gh) | 26.638+8.719s 267.19+15.08MiB | 12.988+3.877s 78.00+15.02MiB  |

    |nixpkgs (gh)          | 27.979+7.699s 447.93+3.34MiB  | 65.614+7.647s 447.41+3.34MiB  |

    |nixpkgs (cb)          | 46.465+9.585s 443.21+3.32MiB  | 121.702+8.869s 442.57+3.32MiB |

    |linux (gh)            | 41.948+11.801s 755.72+2.92MiB | 372.107+11.249s 755.70+2.92MiB|

    |freebsd-src (cb)      | 10.469+3.704s 90.41+3.56MiB   | 4.131+2.173s 6.11+3.56MiB     |

    |----------------------|-------------------------------|-------------------------------|

    |total                 | 195.007s 2032.68MiB           | 227.001s 1757.95MiB           |

@star oh interesting, I wouldn't have thought

@fugi Me neither!! Which is why I added the 5000-limit in the first place. I couldn't possibly have imagined that retrieving >1Mil. commits could somehow be faster than limiting it to only 5000 commits

@star It matches with what this article I recently read details tho: nesbitt.io/2025/12/24/package-managers-keep-using-git-as-a-database.html