BUG: .githooks/pre-push always fails from a worktree — GIT_DIR leaks into git-spawning tests

Abierto
  • ¿Algo no está bien?
#1,020 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@vernonstinebaker ya está trabajando en esto.

Desde el 4/10/2026.

  • #1021 de @vernonstinebaker — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Estancado
Stack tecnológico
git, shell, zig
Área
devtools, testing

Línea de trabajo

A linked pull request (#1021) is already open, so check its status before taking this issue on. If further work is needed, read .githooks/pre-push and the reported git-spawning tests, including skills.test.installSkillFromGit and workspace_audit.test.workspace audit staged diff finds raw token in added line; run the pre-push gate from a worktree with GIT_DIR set. Done means the gate passes there without breaking fixture-repository tests.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

.githooks/pre-push cannot pass when pushed from a git worktree, because git push exports GIT_DIR and every test that spawns git inherits it — then operates on this repository instead of its own temp fixture.

Worktrees are this repo's documented workflow (docs/nullclaw-maintainer-worktree-workflow.md), so the documented flow and the documented gate are mutually exclusive: you either push from a worktree and get a spurious failure, or bypass the hook.

Reproduction

Push from a worktree:

$ cd /path/to/worktree && git push origin my-branch
Running tests...
...
error: 'skills.test.installSkillFromGit installs from local git repository' failed:
error: 'workspace_audit.test.workspace audit staged diff finds raw token in added line' failed:
Build Summary: 11/13 steps succeeded (1 failed); 7380/7400 tests passed (10 skipped, 10 failed)
Tests failed. Fix before pushing.
error: failed to push some refs to '...'

Root cause — reproduced deterministically

Same worktree, same commit:

Environment Result
no GIT_DIR green
GIT_DIR=<worktree gitdir> 7380/7400, 10 failed — the identical set

Failing tests (all of them spawn git against a fixture repo they create):

  • skills.test.installSkillFromGit ×7
  • workspace_audit.test.workspace audit staged diff finds raw token in added line
  • +2 more in the same batch

They read/write the nullclaw repository instead of their temp fixture, so assertions on the fixture's contents fail.

Why a worktree specifically

Verified with a throwaway bare repo and a hook that dumps env | grep ^GIT:

  • push from a normal clone → (no GIT_* exported)
  • push from a worktree → GIT_DIR=/…/.git/worktrees/wt and GIT_PREFIX=

Git must export GIT_DIR from a worktree because .git is a file there, not a directory. A normal clone doesn't need to, which is why this never reproduces outside a worktree.

Impact

  • The pre-push gate is effectively dead for the documented workflow — it always reports failure, so the only ways forward are --no-verify or pushing from the root checkout.
  • Because it fails loudly but wrongly, it also trains people to bypass it, which is exactly what the hook exists to prevent.

Suggested fix

In .githooks/pre-push, clear the inherited git environment before running the suite:

# `git push` from a worktree exports GIT_DIR; tests that spawn `git` for their
# own fixtures would otherwise operate on this repository instead.
unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE GIT_COMMON_DIR GIT_PREFIX

The deeper fix is for the git-spawning tests to sanitize their child environment themselves, so they are correct regardless of how the suite is launched — worth doing as a follow-up, but the one-liner above restores the gate immediately.

Notes

  • Pre-existing, not introduced by any open PR.
  • Found while pushing #1019, which was pushed with --no-verify under AGENTS.md §8.2 after confirming the same suite green manually on Linux and macOS.
Lenguaje dominante
Zig
Estrellas
8.1k
Forks
945
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nullclaw/nullclaw

Todos los issues de nullclaw/nullclaw

Issues similares

Más issues de DevTools

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.