Module pushed_tree 

Run a pre-push check against what is being PUSHED.

rust-test and run-tests-js take their file set from the pushed refs — correct — and then run the suite with current_dir set to the developer’s working tree. So the suite can pass on an uncommitted fix, or fail on an uncommitted experiment, and in neither case has it tested the commits being pushed. Same gap as the pre-commit one, from the other end.

Why not the stash

Holding unstaged changes aside is the pre-commit answer, and it is the wrong instrument here. A push is not a staging operation: the difference that matters is not tree-versus-index but tree-versus-the-commit-you-are-sending, and that includes everything staged-but-uncommitted too. Setting all of it aside for the length of a test suite would leave the developer looking at a tree that is not theirs for minutes at a time.

What it costs, which is the whole question

git worktree add --detach <tip> materialises the pushed commit somewhere else and the suite runs there. The tree is untouched, and an interrupted run leaves a worktree rather than a mangled checkout.

The cost is real: a second checkout, and a build that cannot reuse the primary tree’s target/ cache, so the first push after this lands is a cold build. That is why it is opt-in — git config amont.testPushedTree true — rather than the default. The default keeps today’s behaviour and now SAYS what it is testing, which was the actual bug: not that it used the tree, but that nobody knew it did.

Structs

PushedTree

A checkout of the pushed commit, removed when it goes out of scope.

Functions

enabled

Whether the user asked for the accurate-but-slower answer.

where_to_run

Where a pre-push suite should run, and whether that is the honest answer.