Worktree Git hook paths can get mixed up, so local project hooks may be skipped

[sgaabdu4]

Short version

no-mistakes can create/run an internal worktree where Git hook paths are mixed together.

In plain English: the checkout can look valid, and git push --dry-run can look successful, but the app's own local hooks, such as .husky/pre-push, may not actually be active in that worktree. That means bad changes can pass the local gate and only fail later in CI.

This looks related to #122, which was closed as fixed, but the hook-path problem is still observable on no-mistakes v1.30.1.

Why this matters

There are two different hook systems involved:

1. no-mistakes has its own gate hooks so pushing to the no-mistakes remote starts the pipeline.
2. The user's project may also have hooks, for example Husky .husky/_, .githooks, lefthook, or pre-commit.

Those must not overwrite or confuse each other.

If they do, a user can think this happened:

"My local repo hooks ran, the dry-run was clean, and no-mistakes validated the branch."

But what actually happened may be:

"The no-mistakes worktree did not have the project hooks correctly active, so local checks were skipped. CI caught the problem later."

That is confusing and expensive because users may burn full CI runs for things that should have been caught locally.

What I observed

Environment:

no-mistakes version v1.30.1 (59dfa25) 2026-06-21T22:28:43Z
Git 2.54.0
macOS
husky 9.1.7

In a private React repo using Husky, a no-mistakes internal worktree existed under:

~/.no-mistakes/worktrees/<repo-id>/<run-id>

The matching bare gate repo had more than one hook path configured:

git -C ~/.no-mistakes/repos/<repo-id>.git config --get-all core.hooksPath

Observed shape, with private path details removed:

.husky/_
~/.no-mistakes/repos/<repo-id>.git/hooks

That is the bug signal. The no-mistakes gate repo and the project worktree should not be fighting over core.hooksPath.

After local repair, setting the active project checkout back to a repo-relative Husky path made the project hook check pass again:

core.hooksPath = .husky/_

But this had to be detected and repaired outside of no-mistakes.

Simple repro idea

A minimal repro should be possible with any repo that uses a project hook manager:

mkdir repro && cd repro
git init
npm init -y
npm install -D husky
npm pkg set scripts.prepare=husky
npm run prepare

# Add a project pre-push hook that clearly fails.
printf '#!/bin/sh\necho project pre-push ran >&2\nexit 1\n' > .husky/pre-push
chmod +x .husky/pre-push

git add .
git commit -m 'initial repro'

no-mistakes init
git push no-mistakes HEAD:repro-hooks

Then inspect the no-mistakes gate repo and internal worktree:

git -C ~/.no-mistakes/repos/<repo-id>.git config --get-all core.hooksPath
git -C ~/.no-mistakes/worktrees/<repo-id>/<run-id> config --get-all core.hooksPath

The project hook path should be project-local and active inside the worktree. The no-mistakes gate hook path should remain owned by no-mistakes. They should not both end up in the same shared Git config in a way that makes one silently shadow the other.

Expected behavior

One of these should happen:

1. no-mistakes ensures each pipeline worktree has the project's hooks active before trusting local dry-runs or local push-style checks.
2. Or, if project hooks are intentionally skipped, no-mistakes says that clearly and runs the equivalent checks itself.
3. The bare gate repo's hooks must stay protected from project tools like Husky, and project worktrees must stay protected from no-mistakes-only hook paths.

Actual behavior

The hook path can be ambiguous or wrong in the worktree/gate setup. The result is that local validation can appear to pass even though the project's own hooks did not run.

Helpful check to add

Before declaring a dry-run or pipeline-local push check successful, no-mistakes could verify the active worktree hook path and print a hard error if it points at a no-mistakes-owned path or at a missing project hook directory.

This is not Husky-specific. Husky is just the easiest way to reproduce it because it writes core.hooksPath. The same class can affect any hook manager or repo that relies on project-local Git hooks.

[sgaabdu4]

Adding one bit of workflow context that I should have included in the original report.

The real user flow was not "skip isolation, do some work, then hope no-mistakes catches it." It was the intended flow:

1. Start from a Treehouse worktree for isolated feature work.
2. Do the implementation there.
3. Hand the committed work to no-mistakes for the final validation gate.

That is why this was surprising. Treehouse and no-mistakes together are a very good model: Treehouse gives a clean isolated place to work, and no-mistakes gives a serious gate before pushing/PR/CI. Thank you for building both of them; the workflow is exactly the kind of setup that should prevent this class of mistake.

The bug report is about the handoff/revalidation point: when no-mistakes creates or uses its own internal worktree, it needs to make sure the project hooks are still active there, or say clearly that they are not. Otherwise the overall Treehouse -> implementation -> no-mistakes flow can look safe while one layer of project-local validation was skipped.