pushlisted

# Git Push Preferences for `git push`, especially diagnosing failures. ## Reading push failure output When `git push` exits non-zero, output mixes three layers: - SSH/transport (key offered, accepted) - Hook driver header (lefthook, husky, pre-commit, etc.) - Hook output (test/lint/coverage walls) Identify the failed layer before debugging: - `lefthook` or `hook: pre-push` → pre-push hook failed; transport was fine - `Permission denied (publickey)` → SSH auth refused - `! [rejected]` / `non-fast-forward` → push needs rebase A wall of test or coverage output is NOT an SSH problem. The hook ran tests, the tests failed, the push was blocked. ## pre-push hook failures Same rules as `pre-commit failures` in the commit skill: analyze the failures, autofix when possible, ask the user when unclear. Do NOT skip with `--no-verify` without explicit confirmation. ## Debugging SSH Before adding `-v` to debug an SSH issue, check whether `core.sshCommand` is configured: ``` git config --get core.sshCommand ``` If it returns nothing, `GIT_SSH_COMMAND="ssh -v" git push origin <branch>` is fine. If it returns *anything* (custom IdentityFile, IdentityAgent, deploy-key flags, etc.), DO NOT use `GIT_SSH_COMMAND="ssh -v"`. It REPLACES `core.sshCommand` entirely, dropping every flag. Output will look like the wrong keys are being offered, because they are, but only because you removed the constraint. Append `-v` to the existing command instead: ``` GIT_SSH_COMMAND="$(git config core