fix(prs): gitea_conflict_analyze reports "0 conflicts" for a nonexistent base branch #37

New issue

Closed

opened 2026-10-24 00:59:54 +00:00 by dsh · 1 comment

dsh commented

2026-10-24 00:59:54 +00:00

Owner

Symptom

gitea_conflict_analyze reports a clean/zero-conflict result for branches that do not exist. A typo in base_branch is indistinguishable from a genuinely clean merge, which is unsafe for pre-merge checks.

Repro

gitea_conflict_analyze {owner:"ml-lab", repo:"tardits", head_branch:"master", base_branch:"no-such-base-branch"}
→ Conflict Analysis: 0 conflicting file(s) found between master and no-such-base-branch.


Use gitea_pr_conflict_resolve to preview diff and resolve.

For a real, clean pair the formatter's clean branch should say Conflict Analysis: Clean. ..., but even the valid master/main case earlier printed the same "0 conflicting file(s)" wording (main was deleted on 2026-10-23).

Observed vs expected

Observed: invalid refs silently produce "0 conflicts" and the non-clean sentence.
Expected: an error like base branch "no-such-base-branch" not found (or a failed git merge-tree reason), and for a genuine clean result the Conflict Analysis: Clean. wording.

Root cause

lib/conflict-assistant.js#analyzeMergeConflicts returns a zero-file analysis when refs cannot be resolved instead of propagating a failure; data.clean also appears false for a zero-conflict result (the formatter took the non-clean branch in both valid and invalid cases). The gitea_conflict_analyze formatter only uses data.clean.

Proposed fix

Resolve/verify both refs before analysis and return { ok:false, error: 'branch not found: ...' } when either is missing; make the analysis set clean: true when conflictsCount === 0. Update the formatter to treat conflictsCount === 0 as clean even without the flag. Tests: invalid ref → error; clean pair → "Clean"; conflicting pair → hunk list.

Acceptance: a nonexistent base/head branch never reports "0 conflicts" as success.

Duplicate check

Searched conflict (state all) — #24 covers pr_conflict_resolve wording; this is the analyze path.

Layer

dsh-gitea plugin/tool (conflict assistant + formatter).

## Symptom `gitea_conflict_analyze` reports a clean/zero-conflict result for branches that do not exist. A typo in `base_branch` is indistinguishable from a genuinely clean merge, which is unsafe for pre-merge checks. ## Repro ``` gitea_conflict_analyze {owner:"ml-lab", repo:"tardits", head_branch:"master", base_branch:"no-such-base-branch"} → Conflict Analysis: 0 conflicting file(s) found between master and no-such-base-branch. Use gitea_pr_conflict_resolve to preview diff and resolve. ``` For a real, clean pair the formatter's clean branch should say `Conflict Analysis: Clean. ...`, but even the valid `master`/`main` case earlier printed the same "0 conflicting file(s)" wording (main was deleted on 2026-10-23). ## Observed vs expected - Observed: invalid refs silently produce "0 conflicts" and the non-clean sentence. - Expected: an error like `base branch "no-such-base-branch" not found` (or a failed `git merge-tree` reason), and for a genuine clean result the `Conflict Analysis: Clean.` wording. ## Root cause `lib/conflict-assistant.js#analyzeMergeConflicts` returns a zero-file analysis when refs cannot be resolved instead of propagating a failure; `data.clean` also appears false for a zero-conflict result (the formatter took the non-clean branch in both valid and invalid cases). The `gitea_conflict_analyze` formatter only uses `data.clean`. ## Proposed fix Resolve/verify both refs before analysis and return `{ ok:false, error: 'branch not found: ...' }` when either is missing; make the analysis set `clean: true` when `conflictsCount === 0`. Update the formatter to treat `conflictsCount === 0` as clean even without the flag. Tests: invalid ref → error; clean pair → "Clean"; conflicting pair → hunk list. Acceptance: a nonexistent base/head branch never reports "0 conflicts" as success. ## Duplicate check Searched `conflict` (state all) — #24 covers `pr_conflict_resolve` wording; this is the analyze path. ## Layer dsh-gitea plugin/tool (conflict assistant + formatter).

dsh added the

priority/next

area/forgejo

type/bug

labels

2026-10-24 00:59:54 +00:00

dsh referenced this issue from a commit

2026-10-24 01:11:14 +00:00

fix(prs): correct merged-PR, conflict and readiness semantics (#23, #24, #37, #38)

dsh referenced this issue

2026-10-24 01:11:19 +00:00

fix(prs): correct merged-PR, conflict and readiness semantics #39

dsh commented

2026-10-24 01:11:36 +00:00

Author

Owner

Fixed in 234cbd4 (PR #39).

analyzeMergeConflicts now treats an unresolvable rev-parse as an error: base branch not found: no-such-base-branch / head branch not found: …. A merge-tree failure with no conflict files is also an error instead of a zero-conflict success. The formatter treats conflictsCount === 0 as clean, so a genuine clean pair prints Conflict Analysis: Clean.

Live: no-such-base-branch → clear error; master/master → Conflict Analysis: Clean. Branches "master" and "master" merge cleanly….

Tests: test/pr-semantics.test.mjs.

Fixed in `234cbd4` (PR #39). `analyzeMergeConflicts` now treats an unresolvable `rev-parse` as an error: `base branch not found: no-such-base-branch` / `head branch not found: …`. A `merge-tree` failure with no conflict files is also an error instead of a zero-conflict success. The formatter treats `conflictsCount === 0` as clean, so a genuine clean pair prints `Conflict Analysis: Clean.` Live: `no-such-base-branch` → clear error; `master`/`master` → `Conflict Analysis: Clean. Branches "master" and "master" merge cleanly…`. Tests: `test/pr-semantics.test.mjs`.

dsh closed this issue

2026-10-24 01:11:43 +00:00