feat(runway): git merger SQUASH_REBASE and MERGE

[behinddwalls]

Summary

Why?

The git merger landed with REBASE only. SQUASH_REBASE and MERGE are part of the wire contract SubmitQueue already publishes against, and until they apply here a request naming either is rejected as an invalid request. This adds the two remaining transforming strategies on top of the shared apply machinery.

What?

SQUASH_REBASE applies each change exactly like REBASE — replaying every commit it introduces — then collapses what that change produced into a single commit. The squash unit is the change: a change of ten commits becomes one, and a step whose change carries several URIs yields one commit per URI. Those URIs are a stack of pull requests, and squashing them together would erase the per-PR boundary the stack exists to express.

Two degenerate cases produce no output rather than an empty commit. A change already present on the target creates no commits, so there is nothing to squash. A change that does create commits whose net tree matches the base would squash to an empty commit, so the intermediates are dropped. Both keep redelivery idempotent.

MERGE creates a --no-ff merge commit per change, which keeps the change's original commits reachable through second-parent history — the property that separates it from the picking strategies, which rewrite those hashes. A change already contained in HEAD is skipped rather than merged again.

Not every failed merge is a conflict. applyMerge previously reported any git merge failure as ErrConflict, which tells the client its change collides with the target even when nothing collided. Failures are now classified, and the case that matters in practice is an unrelated history.

Importing an unrelated history. A repository migration arrives as an ordinary change in the target repo whose branch carries the source repo's whole history. Being in the target repo is what makes the commits fetchable; it says nothing about ancestry, and git refuses to merge two graphs with no common ancestor. AllowUnrelatedHistories lifts that refusal for a queue that exists to perform such imports. It is off by default because the refusal is a genuine safeguard — with it always on, merging the wrong object silently produces a nonsense result instead of failing. Without the option, the refusal is now reported as an invalid request rather than a conflict.

MERGE is the only strategy that can serve a migration: it is the only one that preserves the imported commits' original hashes, and the picking strategies have no range to compute across disjoint graphs, so they reject such a change explicitly and say so.

Test Plan

✅ bazel test //runway/extension/merger/git:go_default_test — passes (58s)

New coverage: SQUASH_REBASE collapsing a multi-commit change into one commit while landing all of its content, a two-URI change yielding one squashed commit per URI in application order, SQUASH_REBASE over an already-landed change producing none, MERGE creating one merge commit for a multi-commit change, MERGE skipping a change already an ancestor of the tip, and the MERGE dry-run path.

For migration specifically: importing a three-commit unrelated history and asserting every imported commit is reachable under its original hash, the merge commit has two parents, and the target keeps its own files; redelivery of the same request being a no-op; the import rejected as an invalid request (explicitly not a conflict) when the option is off, leaving the remote and checkout untouched; and both picking strategies rejecting an unrelated history rather than rewriting it.

Stack

1. feat(runway): dlq reconciler for merge topics #459
2. feat(runway): git-backed merger with REBASE #460
3. @ feat(runway): git merger SQUASH_REBASE and MERGE #461
4. feat(runway): git merger PROMOTE #462
5. feat(runway): wire the git merger into the server #463
6. feat(runway): reject changes that disagree on provider #476
7. docs: define the URI as the unit of change #477

[kevinlnew]

AI-generated: isEmptyHEADCommit is dead code — defined but never called. squashChange compares trees via commitTreeSHA directly.

[behinddwalls]

Correct — deleted. It was a leftover from an earlier draft of the squash path that compared HEAD to HEAD^; squashChange ended up comparing the pre-pick tree to the post-pick tree instead, which is the check that actually handles a multi-commit range, and the helper was never wired up. Nothing else referenced it.

[kevinlnew]

AI-generated nit: Parsing cat-file commit output manually to extract the tree SHA. rev-parse ref^{tree} does the same in one call and is less fragile.

[behinddwalls]

Agreed — switched to git rev-parse <ref>^{tree}.

Same one invocation, and it drops the hand-rolled parse along with the "unexpected first line" error branch that existed only because the old form could return something unparseable. rev-parse either resolves the tree or exits non-zero, so the remaining error path is the real one.

Covered by the existing squash tests — the empty-squash case (a change whose net tree matches the base) is decided entirely by this comparison.

[kevinlnew]

Lgtm. Left a couple nits.