A failed push reports only 'failed to push some refs'; the hook's stderr is dropped #465

New issue

Closed

opened 2026-08-27 08:25:27 +00:00 by mph · 1 comment

mph commented

2026-08-27 08:25:27 +00:00

Owner

Found triaging IW-437.

./iw phase-pr failed with exactly this, and nothing else:

Error: Failed to push branch 'IW-437-phase-01': error: failed to push some refs to
'ssh://code.iterative.works:2222/iterative-works/iw-cli.git'

The actual cause was two DisableSyntax.var violations that the pre-push hook had named on stderr, with file, line and column, plus the scalafix command that fixes them. None of that reached the caller. Diagnosing it needed a manual git push to see output the failed command already had in hand.

WHY IT MATTERS. git push's own stderr says only "failed to push some refs" - the hook's report is separate output that the command must forward. A caller reading the message as printed cannot tell a lint block from a rejected non-fast-forward, an auth failure, or a missing remote. For an agent the two plausible next moves - retry the push, or push with --no-verify - are both wrong, and one of them defeats the hook on purpose.

This recurs. It happened again while closing IW-437: the first feature-branch push failed and printed only the bypass banner, and the run had to be repeated to see the reason.

WHERE. phase-pr's push error path (core/commands/PhasePr.scala:115) and whatever env.git.push returns. Any other place a push error is reported should be checked for the same drop.

PROPOSED FIX. Forward the push subprocess's stderr through the failure message rather than replacing it with a summary line.

Found triaging IW-437. ./iw phase-pr failed with exactly this, and nothing else: Error: Failed to push branch 'IW-437-phase-01': error: failed to push some refs to 'ssh://code.iterative.works:2222/iterative-works/iw-cli.git' The actual cause was two DisableSyntax.var violations that the pre-push hook had named on stderr, with file, line and column, plus the scalafix command that fixes them. None of that reached the caller. Diagnosing it needed a manual git push to see output the failed command already had in hand. WHY IT MATTERS. git push's own stderr says only "failed to push some refs" - the hook's report is separate output that the command must forward. A caller reading the message as printed cannot tell a lint block from a rejected non-fast-forward, an auth failure, or a missing remote. For an agent the two plausible next moves - retry the push, or push with --no-verify - are both wrong, and one of them defeats the hook on purpose. This recurs. It happened again while closing IW-437: the first feature-branch push failed and printed only the bypass banner, and the run had to be repeated to see the reason. WHERE. phase-pr's push error path (core/commands/PhasePr.scala:115) and whatever env.git.push returns. Any other place a push error is reported should be checked for the same drop. PROPOSED FIX. Forward the push subprocess's stderr through the failure message rather than replacing it with a summary line.

mph referenced this issue

2026-08-27 08:31:18 +00:00

./iw ./test is green on code the pre-push hook rejects #466

mph referenced this issue

2026-09-01 14:02:50 +00:00

tmux-dependent BATS tests fail non-deterministically under a full ./iw ./test run #468

mph referenced this issue

2026-09-01 15:33:00 +00:00

Hooks and CI read a crashed tool as a finding, and print --no-verify as the remedy #497

mph referenced this issue from a commit

2026-09-02 06:22:12 +00:00

fix(git): carry a blocked push's hook report in the failure

mph referenced this issue

2026-09-02 06:22:57 +00:00

Squash the batch-implement blockers: nine fixes for the phase gate, the CI gate and the review-state card #501

mph commented

2026-09-02 20:55:14 +00:00

Author

Owner

Fixed in PR #501 (merge d1eba9c4). GitAdapter.push now forwards both streams, so a hook that blocks a push says why. All three reporting call sites print the message whole and needed no change.

GitAdapter.commit has the identical defect and was left alone under the smallest-change rule — filed separately.

Fixed in PR #501 (merge d1eba9c4). `GitAdapter.push` now forwards both streams, so a hook that blocks a push says why. All three reporting call sites print the message whole and needed no change. `GitAdapter.commit` has the identical defect and was left alone under the smallest-change rule — filed separately.

mph closed this issue

2026-09-02 20:55:14 +00:00