Add 'merge' command to complete issue workflow from main repo #174

New issue

Open

opened 2026-01-27 14:34:21 +00:00 by mprihoda · 1 comment

mprihoda commented

2026-01-27 14:34:21 +00:00

(Migrated from github.com)

Summary

Add an iw merge <issue-id> command that can be run from the main repository to complete the full issue lifecycle - merging the PR, closing the issue, and cleaning up the worktree.

Problem

Currently, after an issue implementation is complete and the final PR is ready:

We manually merge the PR (via GitHub or gh pr merge)
We manually close the issue (if not auto-closed)
We need to remember to clean up the worktree with iw rm

This is error-prone and leaves orphaned worktrees if we forget the cleanup step.

Proposed Solution

A single command that handles the full completion flow:

# From main repo
iw merge IW-100

What it should do:

Find the PR for the issue branch (e.g., IW-100 → main)
Verify PR is approved/ready to merge
Merge the PR (squash by default, with flag for merge commit)
Close the issue in the tracker (if not auto-closed by PR)
Remove the worktree by calling existing rm command logic
Optionally delete the remote branch

Flags:

--no-squash - Use merge commit instead of squash
--keep-worktree - Don't remove the worktree after merge
--dry-run - Show what would happen without doing it

Example Flow

$ iw merge IW-100
✓ Found PR #173: fix(dashboard): Use Phase Index as source of truth
✓ PR is approved and ready to merge
✓ Merged PR #173 to main (squash)
✓ Issue IW-100 closed
✓ Removed worktree at /home/user/projects/iw-cli-IW-100
✓ Deleted remote branch IW-100

🎉 Issue IW-100 complete!

Acceptance Criteria

Command merges the PR associated with the issue
Command closes the issue if not auto-closed
Command removes the worktree (reuses rm command logic)
Works from the main repository (not from within the worktree)
Handles errors gracefully (PR not ready, conflicts, etc.)
Supports dry-run mode

Notes

Should integrate with existing rm command for worktree cleanup
Consider checking for uncommitted changes in worktree before removal
May need to handle case where worktree doesn't exist (already cleaned up)

## Summary Add an `iw merge <issue-id>` command that can be run from the main repository to complete the full issue lifecycle - merging the PR, closing the issue, and cleaning up the worktree. ## Problem Currently, after an issue implementation is complete and the final PR is ready: 1. We manually merge the PR (via GitHub or `gh pr merge`) 2. We manually close the issue (if not auto-closed) 3. We need to remember to clean up the worktree with `iw rm` This is error-prone and leaves orphaned worktrees if we forget the cleanup step. ## Proposed Solution A single command that handles the full completion flow: ```bash # From main repo iw merge IW-100 ``` **What it should do:** 1. Find the PR for the issue branch (e.g., `IW-100` → main) 2. Verify PR is approved/ready to merge 3. Merge the PR (squash by default, with flag for merge commit) 4. Close the issue in the tracker (if not auto-closed by PR) 5. Remove the worktree by calling existing `rm` command logic 6. Optionally delete the remote branch **Flags:** - `--no-squash` - Use merge commit instead of squash - `--keep-worktree` - Don't remove the worktree after merge - `--dry-run` - Show what would happen without doing it ## Example Flow ```bash $ iw merge IW-100 ✓ Found PR #173: fix(dashboard): Use Phase Index as source of truth ✓ PR is approved and ready to merge ✓ Merged PR #173 to main (squash) ✓ Issue IW-100 closed ✓ Removed worktree at /home/user/projects/iw-cli-IW-100 ✓ Deleted remote branch IW-100 🎉 Issue IW-100 complete! ``` ## Acceptance Criteria - [ ] Command merges the PR associated with the issue - [ ] Command closes the issue if not auto-closed - [ ] Command removes the worktree (reuses `rm` command logic) - [ ] Works from the main repository (not from within the worktree) - [ ] Handles errors gracefully (PR not ready, conflicts, etc.) - [ ] Supports dry-run mode ## Notes - Should integrate with existing `rm` command for worktree cleanup - Consider checking for uncommitted changes in worktree before removal - May need to handle case where worktree doesn't exist (already cleaned up)

mph referenced this issue from a commit

2026-08-21 20:59:52 +00:00

workflow: triage lessons for IW-422 (entries 1-4)

claude referenced this issue

2026-10-16 06:55:30 +00:00

Add iw finish command: merge final PR and remove worktree #249

claude commented

2026-10-16 08:26:51 +00:00

Member

Intake: needs-input

1. Do we build #174 as its own command, or do we put it into `iw finish` from #249?

Open issue #249 asks for iw finish <issue-id>. That command also merges the final PR and removes the worktree, from the main repository. #174 asks for that same work under the name iw merge, plus three items that #249 does not have: close the tracker issue, --dry-run, and --keep-worktree. Question 4 on #249 asks the same thing from the other side and has no answer yet. If we do both issues as they are written, we get two commands that do the same work.

a) Close #174. Put its three extra items into the scope of #249. We get one command, iw finish, and #249 becomes larger.
b) Keep #174 open, but only for its three extra items on iw finish, after #249 lands. #249 stays the same size. #174 must then wait for #249.
c) Build #174 as iw merge and close #249. We get one command with the name merge, and the scope of #174.

Recommended: b): #249 stays the same size, and we lose none of the items in #174. Please give the same answer to question 4 on #249.

2. Must the command merge the final PR with a squash or with a merge commit?

#174 asks for a squash by default, with --no-squash for a merge commit. But each final PR on main merges with a merge commit now, for example 33e14e5f "Merge pull request 'IW-681: …' (#798)". The forge code already has the two merge types: ForgeGateway.scala L75-L105.

"Merge the PR (squash by default, with flag for merge commit)" (issue body)

a) Merge commit by default, with a --squash flag. This is how the project merges now, and the history of each phase stays.
b) Squash by default, with --no-squash. This is what the issue says. Each issue becomes one commit on main.

Recommended: a): it is how the project merges now. Question 1 on #249 asks the same thing, so please give the same answer to both.

Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

Intake: needs-input ### 1. Do we build #174 as its own command, or do we put it into `iw finish` from #249? Open issue #249 asks for `iw finish <issue-id>`. That command also merges the final PR and removes the worktree, from the main repository. #174 asks for that same work under the name `iw merge`, plus three items that #249 does not have: close the tracker issue, `--dry-run`, and `--keep-worktree`. Question 4 on #249 asks the same thing from the other side and has no answer yet. If we do both issues as they are written, we get two commands that do the same work. - **a) Close #174. Put its three extra items into the scope of #249.** We get one command, `iw finish`, and #249 becomes larger. - **b) Keep #174 open, but only for its three extra items on `iw finish`, after #249 lands.** #249 stays the same size. #174 must then wait for #249. - **c) Build #174 as `iw merge` and close #249.** We get one command with the name `merge`, and the scope of #174. **Recommended: b)**: #249 stays the same size, and we lose none of the items in #174. Please give the same answer to question 4 on #249. ### 2. Must the command merge the final PR with a squash or with a merge commit? #174 asks for a squash by default, with `--no-squash` for a merge commit. But each final PR on `main` merges with a merge commit now, for example 33e14e5f "Merge pull request 'IW-681: …' (#798)". The forge code already has the two merge types: [ForgeGateway.scala L75-L105](https://code.iterative.works/iterative-works/iw-cli/src/branch/main/core/adapters/ForgeGateway.scala#L75-L105). > "Merge the PR (squash by default, with flag for merge commit)" (issue body) - **a) Merge commit by default, with a `--squash` flag.** This is how the project merges now, and the history of each phase stays. - **b) Squash by default, with `--no-squash`.** This is what the issue says. Each issue becomes one commit on `main`. **Recommended: a)**: it is how the project merges now. Question 1 on #249 asks the same thing, so please give the same answer to both. Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

claude added the

needs-input

label

2026-10-16 08:26:51 +00:00