chore(branches): default_delete_branch_after_merge did not fire on 4 of 11 merges — mechanism unknown, three hypotheses refuted #633

New issue

Closed

opened 2026-07-31 22:08:53 +02:00 by bosun · 0 comments

bosun commented

2026-07-31 22:08:53 +02:00

Owner

What

default_delete_branch_after_merge = true on this repo, and four merged branches
survived it while seven others in the same window were deleted. No mechanism found.

Filed to preserve the capture, which currently exists only in two chamber contexts that
both compact. It is a cosmetic setting; the value here is the observation, not the branches.

The capture

Taken by @engineer via git ls-remote --heads origin at ~21:58 on 2026-07-31, three
minutes before the four were deleted:

SURVIVED
  40082e3  i/476-manifest-check-go-direct-test      #615  2026-07-30 19:30  merged by bosun
  234bf23  i/476-manifest-check-prerelease-lasttag  #614  2026-07-30 19:18  merged by bosun
  90eff16  i/476-semver-prerelease-bump            (#610)                   merged by bosun
  f503de4  i/476-site3-decide-prerelease-directive  #622  2026-07-31 11:00  merged by bosun

DELETED BY THE SETTING
  #616 02:12 · #618 08:55 · #620 09:29 · #619 09:39   merged by bosun
  #628 15:27 · #631 15:47 · #613 16:02                merged by alex

All four survivors were ancestors of main; nothing was at risk. Deleted via API,
HTTP 204 each, verified 0 remaining by ls-remote.

Three hypotheses, all refuted

TIME    "the setting post-dates those merges"
        REFUTED — #622 survived at 11:00 while #616/#618/#620/#619 (02:12–09:39,
        the SAME day, EARLIER) were all deleted. No time cut separates the sets.

STYLE   "a particular merge method skips it"
        REFUTED — #620 was deleted and was merged fast-forward-only after a 405.

ACTOR   "one merger passes the flag, another does not"
        REFUTED — bosun merged three of the four survivors AND four of the deleted.

⚠️ The pattern that looks real and is not: all four survivors are i/476-* and all
four are @engineer's. Three of the deleted were also his. Not an author effect.

What would discriminate

Whether delete_branch_after_merge was passed per-merge on the API call. The repo
setting supplies a UI default; an API merge that omits the parameter may not inherit it.
Nobody captured the request bodies, and they are not recoverable after the fact.

🔴 This is now unfalsifiable on live state — the four branches are gone, correctly, and
the diagnosis needed them. Answerable only from a future occurrence.

Acceptance criteria## Acceptance criteria

~~On the next batch of merges, record per-merge whether the delete flag was sent, and whether the branch survived — before any cleanup~~ — RETIRED (superseded by direct measurement): PR #988's Verification block directly measured the live API/source behavior; no batch was run.
Determine whether Forgejo's API merge inherits default_delete_branch_after_merge when the parameter is omitted — DONE: PR #988's Verification block records the live Forgejo 15.0.2+gitea-1.22.0 result: the repo setting is true, the merge API cleans up only when the field is sent, and an omitted bool is false.
If it does not inherit: decide whether the merge callsites should pass it explicitly, or whether the repo default should be treated as UI-only and documented as such — DONE: PR #988 implements the explicit manifest-path opt-in, preserves an explicit false policy in the typed client, and documents/tests that decision.
— capture before you remediate

The deletion was correct and I authorised it. The cost is that the diagnosis became
unfalsifiable the moment the fix landed, and a two-line ls-remote before the DELETE
would have made it durable for free.

⚠️ And the capture that saved it was taken by accident — @engineer ran ls-remote to
verify a precondition before a destructive action, not to preserve evidence. The habit
that produced the only surviving record was aimed at something else.

Family: /srv/CLAUDE.md § CAPTURE THE EVIDENCE BEFORE YOU REMEDIATE — the fix destroys
the control.

Anchor

Observed by @engineer 2026-07-31 while checking whether the required-status-check change
(#629) touched anything he held. Hypotheses refuted jointly; capture preserved here at his
request rather than left in two compacting chamber contexts.

## What `default_delete_branch_after_merge = true` on this repo, and **four merged branches survived it** while seven others in the same window were deleted. **No mechanism found.** **Filed to preserve the capture**, which currently exists only in two chamber contexts that both compact. It is a cosmetic setting; the value here is the observation, not the branches. ## The capture Taken by @engineer via `git ls-remote --heads origin` at ~21:58 on 2026-07-31, three minutes before the four were deleted: ``` SURVIVED 40082e3 i/476-manifest-check-go-direct-test #615 2026-07-30 19:30 merged by bosun 234bf23 i/476-manifest-check-prerelease-lasttag #614 2026-07-30 19:18 merged by bosun 90eff16 i/476-semver-prerelease-bump (#610) merged by bosun f503de4 i/476-site3-decide-prerelease-directive #622 2026-07-31 11:00 merged by bosun DELETED BY THE SETTING #616 02:12 · #618 08:55 · #620 09:29 · #619 09:39 merged by bosun #628 15:27 · #631 15:47 · #613 16:02 merged by alex ``` All four survivors were ancestors of `main`; nothing was at risk. Deleted via API, `HTTP 204` each, verified `0` remaining by `ls-remote`. ## Three hypotheses, all refuted ``` TIME "the setting post-dates those merges" REFUTED — #622 survived at 11:00 while #616/#618/#620/#619 (02:12–09:39, the SAME day, EARLIER) were all deleted. No time cut separates the sets. STYLE "a particular merge method skips it" REFUTED — #620 was deleted and was merged fast-forward-only after a 405. ACTOR "one merger passes the flag, another does not" REFUTED — bosun merged three of the four survivors AND four of the deleted. ``` ⚠️ **The pattern that looks real and is not**: all four survivors are `i/476-*` and all four are @engineer's. **Three of the deleted were also his.** Not an author effect. ## What would discriminate Whether `delete_branch_after_merge` was passed **per-merge** on the API call. The repo setting supplies a UI default; an API merge that omits the parameter may not inherit it. **Nobody captured the request bodies**, and they are not recoverable after the fact. 🔴 **This is now unfalsifiable on live state** — the four branches are gone, correctly, and the diagnosis needed them. **Answerable only from a future occurrence.** ## Acceptance criteria## Acceptance criteria - [x] ~~On the next batch of merges, record per-merge whether the delete flag was sent, and whether the branch survived — **before** any cleanup~~ — **RETIRED (superseded by direct measurement):** PR #988's Verification block directly measured the live API/source behavior; no batch was run. - [x] Determine whether Forgejo's API merge inherits `default_delete_branch_after_merge` when the parameter is omitted — **DONE:** PR #988's Verification block records the live Forgejo 15.0.2+gitea-1.22.0 result: the repo setting is true, the merge API cleans up only when the field is sent, and an omitted bool is false. - [x] If it does not inherit: decide whether the merge callsites should pass it explicitly, or whether the repo default should be treated as UI-only and documented as such — **DONE:** PR #988 implements the explicit manifest-path opt-in, preserves an explicit false policy in the typed client, and documents/tests that decision. — capture before you remediate > **The deletion was correct and I authorised it. The cost is that the diagnosis became > unfalsifiable the moment the fix landed, and a two-line `ls-remote` before the `DELETE` > would have made it durable for free.** ⚠️ **And the capture that saved it was taken by accident** — @engineer ran `ls-remote` to verify a precondition before a destructive action, **not to preserve evidence.** The habit that produced the only surviving record was aimed at something else. Family: `/srv/CLAUDE.md` § *CAPTURE THE EVIDENCE BEFORE YOU REMEDIATE — the fix destroys the control.* ## Anchor Observed by @engineer 2026-07-31 while checking whether the required-status-check change (#629) touched anything he held. Hypotheses refuted jointly; capture preserved here at his request rather than left in two compacting chamber contexts.

bosun added the

priority/low

size/S

kind/chore

labels

2026-07-31 22:08:53 +02:00