werkrevisor/docs/prs/2026-10-12-PR#94-merge-conflict.md

PR#94: A PR in Conflict with Its Base Asks for a Rebase, Not for a Human Review

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR documentation is not maintained along with new PRs; treat it as a snapshot.

Problem

werkregie PR#41 asked the human for an approval five times. The first round, for head a30f5d2, started at 13:34:06, the second in which werkregie PR#40 merged into main. The two PRs conflict in dashboard/build.gradle.kts and Config.kt. Gitea refused to schedule the merge with HTTP 405, and werkrevisor noted only "merge not scheduled: POST /repos/mi/werkregie/pulls/41/merge failed with HTTP 405". It still requested the review of the human, who approved three times a PR that could not merge. Only the rebase of the coding agent, 13 minutes later, started a new round.

Non-Goals

• No automatic rebase.
• No change for a PR without a conflict.

Specification

Feature: a PR in conflict with its base asks for a rebase

Scenario#94.01: a YELLOW PR in conflict requests no human review

So that the human approves only a PR that can merge.

• Given a PR whose branch conflicts with its base branch
• When werkrevisor gives the verdict YELLOW
• Then the result comment asks the author to rebase onto the base branch and push, and no human review is requested

Verified by

• test_merge_conflict.MergeConflictTest.test_a_yellow_pr_in_conflict_requests_no_human_review

Scenario#94.02: a GREEN PR in conflict names the conflict

So that the author knows why the approved PR does not merge.

• Given a PR whose branch conflicts with its base branch
• When werkrevisor gives the verdict GREEN
• Then the result comment asks the author to rebase onto the base branch and push

Verified by

• test_merge_conflict.MergeConflictTest.test_a_green_pr_in_conflict_names_the_conflict

Scenario#94.03: a base branch still being checked is no conflict

So that a merge of another PR at the same time does not hold a PR that can merge.

• Given a PR without a conflict, which Gitea still checks after another PR merged into its base branch
• When werkrevisor schedules the merge of the PR
• Then the merge is scheduled, at the latest 5 seconds later

Verified by

• test_merge_conflict.MergeConflictTest.test_a_base_branch_still_being_checked_is_no_conflict

Solution

• Gitea answers 405 to the merge scheduling both for a PR in conflict and while it checks the PR after a merge into its base branch. After a 405, werkrevisor waits 5 seconds and tries once more.
• After a second 405, it reads the PR; if Gitea calls it not mergeable, the gate note asks the author to rebase onto the base branch and push.
• A YELLOW or ORANGE review then requests no human review; a GREEN one approves as before. The note stands in the result comment, like the note of a held merge.
• README and docs/werkrevisor-pr-workflow*.svg: the conflict.
• docs/werkrevisor.werkbaum: #ops.conflict.
• werkrevisor 0.38.0.

Open Questions

None.