Comment by dietr1ch

Comment by dietr1ch 19 hours ago

> merely pulling in Nixpkgs is an effort, due to the repository being massive.

I've embraced daily shallow clone/fetches and the burden is now mostly just the 2GB of disk space.

It's a bit annoying though that git doesn't make it easier. No one would shallow clone later screw up and download every commit anyway, I feel shallow clone repos should be set up with a different configuration that fully-embraces shallow history (not that the configuration options even exist today AFAIK).

dietr1ch 19 hours ago

I just tried 2hrs and it only uses 375M

    git clone \
        --single-branch \
        --shallow-since '-2 hours' \
        --origin 'upstream' \
        gh:NixOS/nixpkgs

What's annoying later is that you MUST remember to always use shallow fetch and hard resets into upstream/$BRANCH

    git fetch \
       --shallow-since '-2 hours' \
       upstream \
       master nixos-unstable

Reply View 3 replies

arikrahman 11 hours ago

Interesting, I have taken a stab at maintaining a repo on the nixpkgs and using a --sparse approach, i.e. `git clone --filter=blob:none --sparse --branch nixos-25.11 https://github.com/NixOS/nixpkgs.git nixpkgs-dorion cd nixpkgs-dorion`

Reply View | 0 replies
aidenn0 15 hours ago

I have a non-shallow clone and the .git directory is less than 3GB.

Reply View | 1 reply
- dietr1ch 12 hours ago
  
  Oh, maybe I had a full clone on my laptop before I started doing shallow fetches, but since fetching takes quite a while I've been using a shallow clone on my workstation.
  
  Reply View | 0 replies

bsimpson 13 hours ago

I've only been doing this for a few weeks, so too early to tell if it's a good setup, but I added a GitHub Action that rebases my personal fork atop nixpkgs-weekly. I'm hoping that will help keep me from having a stale-by-default personal nixpkgs. (I use a personal nixpkgs to stage PRs waiting to be merged upstream.)

https://github.com/appsforartists/nixpkgs/commit/769a72d3a6f...

Reply View 2 replies

dietr1ch 11 hours ago

I remember thinking about doing that, but found value in having my fork tell me when was the last time I synced with upstream which was something useful to assess if I wanted to rebase my patch once again. Eventually my change got upstream and I stopped tracking my own fork though.

Reply View | 1 reply
- bsimpson 9 hours ago
  
  I started doing it this way (auto-rebase) when I started sharing one home-manager config across different devices.
  This lets me do `nix flake update` on my home-manager config to have all my in-flight patches + the canonical nixpkgs from any device, and trust that they can all see the shared GitHub to sync. Hopefully will make updating less of a chore.
  Only time it's bit me so far was when godot3 was broken in nixpkgs-weekly but worked in 25.11. Forced me to go write a PR for that and get it upstream to get my build working again, but that was more of a nixpkgs-weekly problem than a personal fork one.
  One of the wrinkles of getting home-manager going on a bunch of different devices is that it liked to copy my local git checkout of nixpkgs to /nix/store a lot. That's why I'm preferring to have flake.lock point at my github.com branch, and then I can test uncommitted changes as-needed by passing --local to my home-manager switch incantation:
  https://github.com/appsforartists/device-config/blob/c09d6bc...
  
  Reply View | 0 replies