| 4 Apr 2025 |
 Mic92 | Shallow clones are significantly faster for me than downloading tarballs and it's not slower than downloading tarballs for an initial clone. | 10:56:02 |
| Mic92 | * Shallow clones when updating are significantly faster for me than downloading tarballs and it's not slower than downloading tarballs for an initial clone. | 10:56:14 |
| Mic92 | No it's not the default because git inputs have a revcount flag that cannot be computed when doing a shallow clone. | 10:58:58 |
 teto | do you know a reference talking about this : is it a CPU vs bandwidth tradeoff (shallow clones being more CPU intensive) ? | 11:01:14 |
| teto | is revcount that useful ? I never used that I think | 11:01:38 |
| Mic92 | Github uses them in their official checkout action ... | 11:01:49 |
| Mic92 | Agreed but removing it would change evaluation of existing flake.locks | 11:02:31 |
 emily | I think it was CocoaPods or Homebrew or both | 11:19:42 |
| emily | I believe serving shallow clones is expensive, I guess because it is the CPU cost of the Git protocol without the network savings? | 11:19:59 |
| emily | I think they prefer a permanent non-shallow clone that gets fetched normally, or tarball downloads | 11:20:14 |
| Mic92 | Ok. but why is there CI not downloading tarballs? | 13:02:59 |
| emily | no idea :) but I guess CI probably runs a lot less than people hit package indexes | 13:06:03 |
| Mic92 | I think it also makes a big difference if you just do this for nixpkgs instead of many small repos | 13:06:34 |
| Mic92 | Which I think is what CocoaPods is doing | 13:07:11 |
 Alyssa Ross | CocoaPods at the time was one big repo | 13:08:06 |
| Alyssa Ross | I'd imagine it's a lot more expensive with one big repo than with many small ones | 13:08:30 |
| Alyssa Ross | https://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Post-Mortem/ | 13:08:59 |
| Mic92 | Also the question is, if those issues still persist. This was 2016. They have completely revamped their internal git implementation and make it distributed. | 13:15:03 |
| Mic92 | Because I don't see any performance degradation when fetching stuff this way. | 13:16:05 |
| Mic92 | If not, I have even more a reason to fetch my git repository from elsewhere. | 13:17:24 |
| Mic92 | Just checked that cocoapods has 20 times the files of nixpkgs | 13:20:07 |
| emily | feel like hydra distributing nixexprs is still what makes the most sense after all this time :) | 14:05:05 |
| Mic92 | Maybe for some stuff but for my dotfiles, where I am hacking on my nixpkgs fork, the shallow clone is many times faster if I do single commits for bug fixes. | 14:06:19 |
| Mic92 | It should be even cheaper for github to compute this delta over serving me the whole nixpkgs all over again. | 14:07:32 |
 tea | In reply to @qyliss:fairydust.space
https://blog.cocoapods.org/Master-Spec-Repo-Rate-Limiting-Post-Mortem/ If I understand it correctly, the problem here was that cocoa initially did a shallow clone but then upgraded that to a full clone, which is expensive
https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935
| 15:48:46 |
| 5 Apr 2025 |
|  Divya joined the room. | 08:13:38 |
| Divya | : Hello! I wanted to know how Nix packages GHC, does it bootstrap it entirely? How do you guys change the process when GHC changes build systems from 9.4 to 9.6 (from make to hadrian)? | 08:13:52 |
| Divya | I'm from Guix's Haskell team, trying to learn how you guys do it so that we can improve our Haskell situation :) | 08:14:37 |
 K900 | That's more of a #Nixpkgs / NixOS contributions question | 08:14:48 |
| K900 | Or maybe the Haskell room | 08:14:51 |
