[sairus2k]

Problem

Merging a stack of MRs (feature-b → feature-a → main) in one train merged the second MR into feature-a, not main.

GitLab retargets dependent MRs only when the base MR's source branch is deleted on merge, and does it asynchronously. glmt deletes no branches, so after the base merged, the stacked MR still targeted feature-a: the runner rebased it onto feature-a and merged it there. The final pipeline wait then polled main for that merge commit until it timed out.

Fix

Before rebasing an MR, the runner checks whether its target branch is the source branch of an MR already merged by this train. If so, it retargets the MR to the train's target branch via the new Client.UpdateMergeRequestTargetBranch (PUT /merge_requests/:iid with target_branch), then rebases and merges as usual.

• Base skipped (conflict, not mergeable, …) → every MR stacked on it is skipped with base branch X was not merged, instead of merging into a branch that never reached main.
• Retarget fails → the MR is skipped, and so is the stack above it.
• The TUI shows a Retarget to main step, and the rebase label names the new target.

Commits

1. fix(train) — client method (API, demo, logging, mocks) and runner logic
2. fix(tui) — retarget step and rebase label
3. test(e2e) — stack of three MRs
4. docs — README note on stacked MRs

Verification

• Runner: table test over a 3-MR stack — all merged with retargets ordered before each rebase; skipped base skips the stack; failed retarget skips the MR and the stack above it.
• Client: httptest for the request body and error wrapping. TUI: model-state test for the step names.
• E2E (GitLab CE 18.8.5, go test -tags e2e, passed in 499s): a stacked MRs subtest reuses the TestTrainMergesMRs container, since a second boot would not fit the 25-minute CI timeout. It moves main after creating the stack so the base rebase rewrites its commits, then asserts all three MRs are merged into main and each commit appears on main exactly once — GitLab's rebase drops the stale copies of the base's commits.

Not covered

A stacked MR queued before its base still merges into the base branch, as before. The README now says to select the base first.