Current (c38ef9362) version of numtide/prj-spec/contrib/direnv misbehaves when using linked git worktrees

[cscutcher]

Hopefully, I've got somewhere near to the cause of the issue in numtide/prj-spec#4 but opening issue here to help with tracking.

This occurs when using a "linked" git worktree (i.e. a worktree created with git worktree add).

Due to using git rev-parse --absolute-git-dir to discover the PRJ_ROOT in numtide/prj-spec#4 , PRJ_ROOT ends up being defined pointing to the git state directory for the linked worktree. For example see this abridged trace output;

direnv: loading /mnt/user_persist/git/nix/nixos-geralt/.envrc
...
++ source /home/cscutcher/.cache/direnv/cas/4772bc165bdba2f8f820ebdd95636d40a2cc312415e3ae168c6f5e536f62c479
...
++++ fetchurl https://raw.githubusercontent.com/numtide/prj-spec/1ac38ef93620cd2d632e397cb36d23b0c65aeeed/contrib/direnv sha256-E03RxkkiZpTcsNGqymCe3Q/U/A6Tg9jUjMsRlW+1bzE=
++++ /nix/store/gmiiyc125cq7x0fvbvvyhr1vzgb3dfqx-direnv-2.32.2/bin/direnv fetchurl https://raw.githubusercontent.com/numtide/prj-spec/1ac38ef93620cd2d632e397cb36d23b0c65aeeed/contrib/direnv sha256-E03RxkkiZpTcsNGqymCe3Q/U/A6Tg9jUjMsRlW+1bzE=
+++ source /home/cscutcher/.cache/direnv/cas/134dd1c649226694dcb0d1aaca609edd0fd4fc0e9383d8d48ccb11956fb56f31
++++ : /home/cscutcher/.config
++++ : /home/cscutcher/.cache
++++ : /home/cscutcher/.local/share
+++++ git rev-parse --absolute-git-dir
++++ : /mnt/user_persist/git/nix/nixos/.git/worktrees/some-worktree
++++ _prj_root=/mnt/user_persist/git/nix/nixos/.git/worktrees/some-worktree

This leads to the later nix commands looking like this;

nix build --no-update-lock-file --no-write-lock-file --no-warn-dirty --accept-flake-config --no-link --keep-outputs --build-poll-interval 0 --builders-use-substitutes --print-out-paths --profile /mnt/user_persist/git/nix/nixos/.git/worktrees/some-worktree/.data/x6/devshells/default/enter-action git+file:///mnt/user_persist/git/nix/nixos/.git/worktrees/some-worktree#__std.actions.x86_64-linux.x6.devshells.default.enter

tl;dr; I think the fix is in numtide/prj-spec#4 but additional context/investigation below in case it's helpful

---

Wwhat really threw me, was that it fails somewhat silently. What seems to happen instead is that the devshell version on the "main" git worktree (e.g. /mnt/user_persist/git/nix/nixos/ in this example) was used instead! (*As it turns out, this isn't consistent. Sometimes it'll just be the "wrong" commit). This was perplexing, since I was making modifications in the linked worktree, but they weren't having any effect.

I haven't been able to work out exactly what nix is doing when it encounters the .git/worktree/some-worktree URL. At first, I assumed it was just using the commit on the main worktree instead of the linked one, but it does appear to be aware, to an extent, that the worktree is different, only it finds the wrong (seemingly outdated) commit ref.

Although whether nix is behaving sensibly when interpreting a git+file://.../.git/worktrees/some-worktree or not, is probably irrelevant here since it would be inconsistent to use the work tree when running devshell in the "main" git work tree (equivalent to git rev-parse --show-toplevel which will be the same as "${GIT_DIR%/.git}" in this case), but then use a "git dir" (equivalent to git rev-parse --absolute-git-dir) for a linked git work tree.

Is this a nix bug?

I'm on the fence about whether to consider this a bug against nix itself too, since it does seem odd that using a `git+file://.../.git/worktrees/some-worktree` as the flake URL *almost* works in a way that is arguably worse than if it just failed explosively (assuming I've not made any mistake in my end) .

Then again, I don't think I've seen git itself or other tools visibly use the .git/worktrees/some-worktree path directly, so arguably it's a bit of an edge case.
In any case

edit: Forgot to mention a workaround

Adding;

PRJ_ROOT=$(git rev-parse --show-toplevel)
export PRJ_ROOT

before the source "$(fetchurl "https://raw.githubusercontent.com/paisano-nix/direnv/main/lib" "sha256-R3K8Flvbovj4IOvdlWNtQKLMMSQV464WjG9eU29ixHk=")" seems to work around the issue.