allod-parity and go-checks fail from a linked worktree: path: copies a dangling .git file #284

Open
opened 2026-10-22 03:19:54 +01:00 by allod-agent · 0 comments
Member

Building allod-parity or go-checks with a path: flake reference from a linked git worktree fails, while the same build from the primary checkout passes. The failure signature is allod: invalid description '<desc>'; use only letters, numbers, '.', '_', and '-' for a description that is plainly valid (t218-no-origin, memory-backpass-2026-10-22).

Mechanism

validDescription in cmd/allod/change.go ends with git check-ref-format --branch agent/<desc> run in the caller's current directory. The path: fetcher copies the source tree verbatim, including .git. In the primary checkout .git is a directory and git works inside the copy. In a linked worktree .git is a one-line file (gitdir: /abs/path/.git/worktrees/<name>) whose target does not exist in the build sandbox, so every git invocation under the copied tree fails with fatal: not a git repository: (null), and the validator reports the description as invalid. The parity tests and TestMemoryBackpass* both call allod change begin -d with the copied tree as cwd, so they are the tests that surface it.

Reproduce without Nix: copy a worktree's .git file into an empty directory, edit its path to something nonexistent, and run git check-ref-format --branch agent/x there. It exits 128 with not a git repository.

Fix options

  • Make validDescription independent of the cwd: git check-ref-format --branch does not need a repository, so run it with GIT_DIR pointed at an empty directory, or with cwd set to a known non-repository such as the system temp root.
  • Or strip .git from src in flake.nix (lib.cleanSource or builtins.path with a filter) so the checks never see a repository at all, which matches what the git fetcher does for .# references.

The first is smaller and also fixes any other git call in allod that assumes its cwd is sane. Noticed while validating allod/tools#281 from an allod change begin -d worktree; the change under test did not touch cmd/allod.

Building `allod-parity` or `go-checks` with a `path:` flake reference from a linked git worktree fails, while the same build from the primary checkout passes. The failure signature is `allod: invalid description '<desc>'; use only letters, numbers, '.', '_', and '-'` for a description that is plainly valid (`t218-no-origin`, `memory-backpass-2026-10-22`). ### Mechanism `validDescription` in `cmd/allod/change.go` ends with `git check-ref-format --branch agent/<desc>` run in the caller's current directory. The `path:` fetcher copies the source tree verbatim, including `.git`. In the primary checkout `.git` is a directory and git works inside the copy. In a linked worktree `.git` is a one-line file (`gitdir: /abs/path/.git/worktrees/<name>`) whose target does not exist in the build sandbox, so every git invocation under the copied tree fails with `fatal: not a git repository: (null)`, and the validator reports the description as invalid. The parity tests and `TestMemoryBackpass*` both call `allod change begin -d` with the copied tree as cwd, so they are the tests that surface it. Reproduce without Nix: copy a worktree's `.git` file into an empty directory, edit its path to something nonexistent, and run `git check-ref-format --branch agent/x` there. It exits 128 with `not a git repository`. ### Fix options - Make `validDescription` independent of the cwd: `git check-ref-format --branch` does not need a repository, so run it with `GIT_DIR` pointed at an empty directory, or with cwd set to a known non-repository such as the system temp root. - Or strip `.git` from `src` in `flake.nix` (`lib.cleanSource` or `builtins.path` with a filter) so the checks never see a repository at all, which matches what the git fetcher does for `.#` references. The first is smaller and also fixes any other `git` call in `allod` that assumes its cwd is sane. Noticed while validating allod/tools#281 from an `allod change begin -d` worktree; the change under test did not touch `cmd/allod`.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
allod/tools#284
No description provided.