The stash that would have deleted the work it was protecting

Description and use

Using git stash in a long‑lived shared checkout caused uncommitted work to be lost when a reference‑transaction hook blocked stashes. The stash‑based heal was removed and replaced with committing dirty trees and investigation tasks.

Problem

Using git stash in a long‑lived, shared checkout caused a hard reset to discard uncommitted work when a reference‑transaction hook blocked stashes.

Outcome

The stash‑based heal was unsafe; the hook caused a hard reset to lose work. Removing the stash logic and committing dirty files instead prevented data loss and surfaced hidden changes.

Workflow

• 1. Check if tree is dirty and main diverged.
• 2. Attempt to stash with git stash push --include-untracked (blocked by hook).
• 3. Replay local commits onto origin/main; if fails, reset hard to origin/main.
• 4. If stash succeeded, pop it; if pop fails, reset to HEAD.
• 5. In new logic: commit dirty tree, raise investigation task, push changes.

Evidence

Since June, a reference‑transaction hook in it refuses every write to refs/stash. Stashes are banned there

Source

The step meant to keep the work safe is exactly the step that, when it fails, leaves the work in the path of a hard reset.

Source

The lane’s start‑of‑run flush commits the stranded files with a path‑scoped commit, and the next cycle heals.

Source