Just tried using nix-direnv for the first time; it seems it doesn't work with git worktrees?

$ cd nixvim/docs_raw_submodule/
direnv: error /home/matt/nixvim/docs_raw_submodule/.envrc is blocked. Run `direnv allow` to approve its content
$ direnv allow
direnv: loading ~/nixvim/docs_raw_submodule/.envrc
direnv: using flake
error:
       … while fetching the input 'git+file:///home/matt/nixvim/docs_raw_submodule'

       error: '/home/matt/nixvim/docs_raw_submodule' is not a Git repository
direnv: nix-direnv: Evaluating current devShell failed. Falling back to previous environment!
direnv: export +NIX_DIRENV_DID_FALLBACK ~PATH

In this example ~/nixvim is a "bare" git repo and docs_raw_submodule is a worktree created using git worktree add

I used to have the default branch checked out at the top-level and then have feature branches checked out in nested worktrees, but I found it annoying how the nested worktrees showed up as untracked files in the top-level worktree, figured a bare repo was cleaner.

Do you recall why someone on stackoverflow recommended against using a bare checkout? Was it just because some tooling might be expecting a .git dir? I find most tools use libgit or something similar, so it usually isn't an issue.

IDK if the sheer quantity of builds we're currently running in nixvim is contributing, but we're running into buildbot issues with cross-comp/available builders rather frequently, leading to us having to rebuild to get a green checkmark (putting even more strain on resources)...

e.g. this is from a recent build (from this eval):

Failed to find a machine for remote build!
derivation: ycm30n2fwjwycmx3hi21gvn1q4kr04yy-plugins-ui-zen-mode.drv
required (system, features): (aarch64-linux, [])
2 available machines:
(systems, maxjobs, supportedFeatures, mandatoryFeatures)
([aarch64-linux], 80, [benchmark, big-parallel, gccarch-armv8-a, kvm, nixos-test], [])
([aarch64-darwin, x86_64-darwin], 8, [big-parallel], [])
error: a 'aarch64-linux' with features {} is required to build '/nix/store/ycm30n2fwjwycmx3hi21gvn1q4kr04yy-plugins-ui-zen-mode.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

I've seen that occur a few times in other projects on buildbot as well.

I'm wondering if we can group our tests a little more whether that'd help; that way there'd be a smaller number of bigger builds.

We split them up so much originally to reduce RAM usage. But it's ended up causing other issues, such as many small builds waiting for builders to become available.

For now the rebuilds aren't too much strain on our resources.

That's reassuring!

e.g. smarter scheduling and making no op rebuilds faster.

Yeah only rebuilding the failed builds would be good. Cancelling an eval & its builds when a new one is triggered on the same PR could be worthwhile too, at least on repos where the builds are heavy?