feat(pulls/merge): add --delete-branch flag #3

Merged

jmz merged 1 commit from maximus/feat/delete-branch-flag-v2 into release/mirus

2026-05-06 23:32:22 +00:00

jmz commented

2026-05-06 23:31:32 +00:00

Owner

Re-targets the same change from closed #1 onto release/mirus per the model-A architecture.

Summary

Surfaces the existing DeleteBranchAfterMerge field from the Gitea SDK's MergePullRequestOption on tea pr merge. Mirrors the web UI's "Delete branch after merge" checkbox.

Invocation	Result
`tea pr merge 42`	Field unset → server applies its repo-level `default_delete_branch_after_merge` setting.
`tea pr merge 42 --delete-branch`	Force-deletes the head branch on success.
`tea pr merge --delete-branch` (interactive)	Same, in the interactive picker.

Pointer-to-bool semantics keep "omitted" distinct from "explicitly false".

Why on release/mirus and not main

Per the fork's model-A architecture: main is a clean upstream mirror; local Mirus patches accumulate on the long-lived release/mirus branch which is what release tags v*+mirus.* build from. Closed PR #1 was retargeted here.

Test plan

make test passes (CI on release/mirus runs make clean && make vet && make build per the just-added .forgejo/workflows/check.yml).
Spot-check interactive path still works.

Re-targets the same change from closed [#1](../pulls/1) onto `release/mirus` per the model-A architecture. ## Summary Surfaces the existing `DeleteBranchAfterMerge` field from the Gitea SDK's `MergePullRequestOption` on `tea pr merge`. Mirrors the web UI's "Delete branch after merge" checkbox. | Invocation | Result | |---|---| | `tea pr merge 42` | Field unset → server applies its repo-level `default_delete_branch_after_merge` setting. | | `tea pr merge 42 --delete-branch` | Force-deletes the head branch on success. | | `tea pr merge --delete-branch` (interactive) | Same, in the interactive picker. | Pointer-to-bool semantics keep "omitted" distinct from "explicitly false". ## Why on release/mirus and not main Per the fork's model-A architecture: `main` is a clean upstream mirror; local Mirus patches accumulate on the long-lived `release/mirus` branch which is what release tags `v*+mirus.*` build from. Closed PR [#1](../pulls/1) was retargeted here. ## Test plan - [ ] `make test` passes (CI on release/mirus runs `make clean && make vet && make build` per the just-added `.forgejo/workflows/check.yml`). - [ ] Spot-check interactive path still works.

jmz added 1 commit

2026-05-06 23:31:32 +00:00

feat(pulls/merge): add --delete-branch flag

check / check (pull_request) Successful in 35s

Details

f07ef88049

Surfaces the existing ``DeleteBranchAfterMerge`` field on the Gitea
SDK's ``MergePullRequestOption`` so callers can opt into deleting the
head branch after a successful merge. Mirrors the web UI checkbox.

Default behaviour unchanged: when the flag is omitted, the field stays
nil and the server applies its repo-level
``default_delete_branch_after_merge`` setting. So repos that already
have auto-delete configured will start deleting branches once their
contributors run ``tea pr merge`` from this build.

Pointer-to-bool semantics: setting --delete-branch=false would
currently mean "don't pass the field" rather than "explicitly false".
If a future caller needs to override the repo default to-false
explicitly, switch to IsSet()-aware threading then; not needed today.

Both call sites updated:
- cmd/pulls/merge.go (non-interactive)
- modules/interact/pull_merge.go (huh-driven interactive selection)

Closes the gap surfaced on srv-mirus on 2026-05-06: dg repo had
``default_delete_branch_after_merge=True`` but tea pr merge wasn't
sending the field, so merged stage-1/2/3 branches survived. Manual
DELETE /branches cleanup was the workaround.

jmz merged commit f07ef88049 into release/mirus

2026-05-06 23:32:22 +00:00

jmz referenced this pull request

2026-05-06 23:42:52 +00:00

ci: add Forgejo-specific workflows to main (operational config for tag-triggered releases) #4