# 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](../../tests/test_merge_conflict.py)

#### 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](../../tests/test_merge_conflict.py)

#### 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](../../tests/test_merge_conflict.py)

## 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.