* Accept PR URLs in link and checkout commands
Add support for GitHub PR URLs (e.g. https://github.com/owner/repo/pull/42)
as arguments to `gh stack link` and `gh stack checkout`, in addition to
the existing PR number and branch name support.
For `link`: PR URLs are parsed in findExistingPR before the numeric check.
Unlike numeric args, if a URL-extracted PR number doesn't exist, the command
errors immediately rather than falling through to branch name lookup (since
a URL can never be a valid branch name).
For `checkout`: PR URLs are parsed in runCheckout before the numeric check,
routing to resolveNumericTarget which supports both local and remote API
fallback — same behavior as passing a PR number directly.
Closes#115
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* update docs
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When a user runs `gh stack submit` and an existing PR is discovered for
a branch via `FindPRForBranch`, that PR may have auto-merge enabled.
Auto-merge is incompatible with stacked PRs because the PR would merge
on its own, breaking the stack's base chain.
Previously, the eligibility guard for auto-merge was only in the `link`
command (which blocks such PRs with an error). The `submit` command had
no such check, allowing users to add auto-merge-enabled PRs to a stack
by running `init` followed by `submit`.
This change adds auto-merge detection and automatic disabling in
`submit`'s `ensurePR` function. When an existing PR with auto-merge
enabled is discovered, the CLI disables auto-merge via the
`disablePullRequestAutoMerge` GraphQL mutation and warns the user.
If the disable call fails, submit continues with a warning (non-fatal).
The `link` command retains its stricter behavior of blocking auto-merge
PRs outright, since the user explicitly chose those PRs and can fix
them before retrying.
Changes:
internal/github/github.go:
- Add DisableAutoMerge() method using the
disablePullRequestAutoMerge GraphQL mutation
internal/github/client_interface.go:
- Add DisableAutoMerge(prID string) error to ClientOps interface
internal/github/mock_client.go:
- Add DisableAutoMergeFn field and mock implementation
cmd/submit.go:
- In ensurePR, after discovering an existing PR with auto-merge
enabled, call DisableAutoMerge before proceeding. Warns on
success ("Disabled auto-merge for PR #N (incompatible with
stacked PRs)") and on failure ("failed to disable auto-merge").
cmd/submit_test.go:
- Add TestSubmit_DisablesAutoMergeOnExistingPR: verifies auto-merge
is disabled and warning is shown
- Add TestSubmit_DisableAutoMergeFailure_ContinuesWithWarning:
verifies submit continues even if the disable call fails
- Add TestSubmit_NoAutoMerge_SkipsDisable: verifies DisableAutoMerge
is not called for PRs without auto-merge
When users authenticate the GitHub CLI with a personal access token
(PAT) instead of OAuth (`gh auth login`), the `cli_internal` stacks
API endpoints return 404. The CLI previously interpreted this as
"Stacked PRs are not enabled for this repository," which is misleading
— the feature may be enabled, but the token type simply cannot access
the internal endpoints.
This is a recurring source of user confusion. The docs already note
that PATs are not supported, but users don't always read them before
hitting the error.
This change adds token-type detection by inspecting the `gh` auth
token prefix:
- `gho_` → OAuth (supported)
- `ghs_` → GitHub App installation token (supported)
- `ghp_` → Classic PAT (NOT supported)
- `github_pat_` → Fine-grained PAT (NOT supported)
When a PAT is detected, the CLI now shows:
⚠ Personal access tokens are not supported by gh stack
Run `gh auth login` to authenticate with OAuth instead.
Instead of the misleading:
⚠ Stacked PRs are not enabled for this repository
Changes:
- Add `internal/config/auth.go` with auth detection methods on Config:
`IsPersonalAccessToken()`, `WarnIfPAT()`, and `RepoHost()`. Uses a
`TokenForHostFn` field on Config for test overrides, following the
same pattern as `GitHubClientOverride`.
- Add a pre-flight PAT check in `cmd/submit.go` before the
`ListStacks` call. If a PAT is detected, the command aborts early
with a clear error instead of making a doomed API call.
- Update all 404 handlers for `cli_internal` endpoints to check the
token type and show the appropriate message:
- `cmd/submit.go` (createNewStack)
- `cmd/link.go` (listStacksSafe, createLink)
- `cmd/checkout.go` (checkoutRemoteStack)
- Add `warnStacksUnavailableOrPAT()` helper in `cmd/utils.go` that
shows the PAT-specific warning when applicable, falling back to the
generic "not enabled" message for non-PAT tokens.
- Add unit tests in `internal/config/auth_test.go` for token prefix
detection and warning output.
- Add integration tests in `cmd/submit_test.go` verifying that both
classic PATs (`ghp_`) and fine-grained PATs (`github_pat_`) trigger
the pre-flight check and abort before any API calls.
- Add `warnStacksUnavailableOrPAT` tests in `cmd/utils_test.go`
verifying correct message selection based on token type.
- Update existing 404 tests to explicitly set an OAuth token so they
continue exercising the ListStacks 404 path.
The `link` command previously allowed PRs in any state to be added to a
stack, including PRs that had already been merged, were closed, were
sitting in a merge queue, or had auto-merge enabled. Adding such PRs to
a stack is invalid because they have already been or will soon be merged,
which breaks the stacked PR workflow.
Add a new validation phase (Phase 2b) to `runLink` that checks the
eligibility of every existing PR found during lookup, before any new PRs
are created or stack operations are performed. Only open/draft PRs
without auto-merge enabled are eligible. All ineligible PRs are reported
at once with a clear per-PR error message indicating the specific reason
(merged, closed, in merge queue, or auto-merge enabled).
Changes:
internal/github/github.go:
- Add AutoMergeRequest struct and field on PullRequest
- Add IsAutoMergeEnabled() method on *PullRequest
- Update FindPRByNumber and FindPRForBranch GraphQL queries to fetch
the autoMergeRequest field
internal/github/github_test.go:
- Add TestPullRequest_IsAutoMergeEnabled (nil, non-nil, nil receiver)
cmd/link.go:
- Add pr field to resolvedArg to retain full PR data from lookup
- Add validatePREligibility() that rejects merged/closed/queued/
auto-merge-enabled PRs with descriptive error messages
- Wire validation into runLink between PR lookup and stack operations
cmd/link_test.go:
- Add 7 tests covering each disallowed state by PR number and branch
name, plus a multi-invalid-PR reporting test
* Add `gh stack trunk` navigation command
Add a new navigation command that checks out the trunk branch of the
current stack.
The command is stack-aware: it requires the user to be on a branch that
is part of a stack, loads the stack metadata, and checks out `s.Trunk.Branch`.
If the user is already on the trunk branch, it prints a message and exits
without calling git checkout.
New files:
- cmd/trunk.go: TrunkCmd (cobra command) + runTrunk implementation
- cmd/trunk_test.go: 7 test cases covering happy path, already on
trunk, from top of stack, not in a stack, checkout failure, custom
trunk branch name, and positional argument rejection
Modified files:
- cmd/root.go: register TrunkCmd in the "nav" command group
- README.md: add `gh stack trunk` to the Navigation section
- docs/src/content/docs/reference/cli.md: add `gh stack trunk`
reference section
* address review comments
* increment skill version
* add insert branch operation to modify TUI
Add `i` (insert below) and `I` (insert above) key bindings to the
interactive modify view, allowing users to insert new empty branches
into an existing stack. This follows Vim-inspired semantics where
lowercase `i` inserts below the cursor and uppercase `I` inserts above.
## TUI behavior
When the user presses `i` or `I`, the TUI enters an insert input mode
(similar to rename mode) where they type a new branch name. The input
is validated against git ref naming rules, local branch uniqueness, and
in-stack name collisions. On confirm, a placeholder node is inserted at
the correct position in the branch list with a green "✚ insert"
annotation badge and green connector styling.
Insert is a structure operation — it works alongside fold, rename, and
drop, but is mutually exclusive with reorder (consistent with existing
mode exclusivity rules). Undo (`z`) removes the inserted node cleanly.
## Apply engine
At apply time (Step 2 in the pipeline, between renames and folds), the
engine creates the new git branch at the parent branch's tip via
`git.CreateBranch` and inserts a `BranchRef` into the stack metadata at
the correct position. If the insertion changes the base of a branch
that has an open PR, `affectsPRs` is set to trigger a required
`gh stack submit` afterward.
## Header shortcut updates
- Combined the fold shortcuts into a single line: `d/u - fold down/up`
- Added insert shortcuts on their own line: `i/I - insert below/above`
- Reordered fold references throughout to list "down" before "up" for
consistency with the insert shortcut ordering
## Files changed
- types.go: ActionInsertBelow/ActionInsertAbove types, IsInserted field,
InsertedBranches in ApplyResult
- model.go: key bindings, insert input mode, undo, mode exclusivity,
annotation, styling, header shortcuts, effective-index tracking to
prevent false reorder detection when inserts shift node positions
- styles.go: green insert badge/branch/connector styles
- status.go: insert counting in pending change summary
- help.go: new "Insert below / above" section, reordered fold heading
- apply.go: BuildPlan and ApplyPlan handle insert actions
- modify.go: updated command description and success summary
- README.md: updated keybindings table
## Test coverage
- 16 new TUI tests: insert below/above, top/bottom edges, undo, mode
exclusivity, merged branch guard, cancel/empty input, duplicate name
validation, pending summary counting, annotation rendering, mixed
operations with drop/fold, apply acceptance
- 4 new apply tests: BuildPlan produces correct insert actions,
ApplyPlan creates branches and updates stack metadata, insert at
stack start uses trunk as parent, affectsPRs triggered when inserting
before a branch with an open PR
* update add error msg to direct users to modify for inserting branches
* docs updates
* fix insert branch bugs in modify TUI
Fix three bugs with the insert branch feature in the modify TUI, and
adjust rename behavior on inserted nodes.
## Bug 1: False "moved" annotations on existing branches
After inserting a branch, all branches below the insertion point
displayed "↕ moved 1 layer down" annotations. This happened because
`nodeAnnotation` and `toNodeData` compared each node's
`OriginalPosition` against its raw array index, which gets shifted
when an inserted node is added to the slice.
Fix: introduce an `effectiveIdx` parameter that counts only
non-inserted nodes, so position comparisons reflect the original
ordering. The View loop computes effective indices by incrementing
only for non-inserted nodes and passes them to the rendering
functions.
## Bug 2: Header branch count inflated by staged inserts
The branch count in the header ("N branches") included inserted
placeholder nodes, making it appear as though the stack had grown
before changes were applied.
Fix: `buildHeaderConfig` now excludes `IsInserted` nodes from the
branch count. The count reflects only the original branches in the
stack.
## Bug 3: Operations allowed on inserted placeholder nodes
Inserted nodes could be folded into other branches, which makes no
sense for a placeholder with no commits. Additionally, the "last
branch" guard counted inserted nodes as active, allowing users to
drop all original branches and bypass the empty-stack check.
Fix:
- `fold()` rejects inserted nodes with a descriptive error message.
- `toggleDrop()` on an inserted node removes it entirely and pops
the original insert action from the undo stack (clean cancellation
rather than a separate undo entry).
- All three "active branch" guards (`toggleDrop`, `fold`, `tryApply`)
now exclude `IsInserted` nodes, ensuring at least one original
branch always remains in the stack.
## Rename on inserted branches
Instead of blocking renames on inserted nodes, pressing `r` now
enters rename mode and updates the insert action's name in place.
The node's `Ref.Branch` and `PendingAction.NewName` are both updated
directly — no separate rename action is created in the undo stack.
This lets users fix a typo without having to drop and re-insert.
## Tests added
- `TestInsertDoesNotShowMovedAnnotation` — verifies no false move
annotations appear on existing branches after an insert
- `TestBranchCountExcludesInserts` — verifies header count stays
stable after insert
- `TestCannotFoldInsertedBranch` — verifies fold is blocked
- `TestCannotRenameInsertedBranch` — verifies rename updates the
insert name in place
- `TestDropInsertedBranchRemovesIt` — verifies drop removes the node
- `TestDropInsertedBranchCanBeUndone` — verifies drop pops the
original insert from the undo stack
- `TestCannotDropAllOriginalBranchesWithInsert` — verifies the
empty-stack guard excludes inserted nodes
* ensure cannot fold into an inserted branch
* rm dead code
* delete inserted branches during abort
* modify: only require submit when changes affect PRs
Previously, `gh stack modify` always transitioned to `PhasePendingSubmit`
after completing on any stack with a remote ID (`s.ID != ""`). This blocked
the user from running another `modify` until they ran `gh stack submit`,
even when the modifications only touched local branches without PRs.
This was overly restrictive. If a user is working at the top of their stack
with branches that haven't been pushed or had PRs created yet, restructuring
those branches is a purely local operation — there is no remote state to
reconcile, and no reason to force a submit before allowing further modifies.
## What changed
The condition for entering `PhasePendingSubmit` is now
`s.ID != "" && affectsPRs` instead of just `s.ID != ""`.
A new `affectsPRs` flag is tracked throughout the apply process. It is set
to `true` when any of the following occurs:
- A **renamed** branch has a `PullRequest` ref
- A **folded** branch (source or target) has a `PullRequest` ref
- A **dropped** branch has a `PullRequest` ref
- A **rebased** branch (during cascading rebase) has a `PullRequest` ref
If none of these conditions are met, the modify state file is cleared
immediately — no pending-submit lock, no "run `gh stack submit`" prompt.
## Changes by file
**`internal/modify/state.go`**
- Added `AffectsPRs bool` field to `StateFile`. This persists the flag
across conflict boundaries so that `ContinueApply` knows whether
actions applied before the conflict already affected PR branches.
**`internal/modify/apply.go`**
- `ApplyPlan`: tracks `affectsPRs` through each step (rename, fold, drop,
rebase). Saves the flag into conflict state when a conflict occurs.
Uses `s.ID != "" && affectsPRs` for the pending-submit decision.
- `ContinueApply`: initializes `affectsPRs` from the saved state file,
then checks the conflict branch and remaining branches for PRs during
the cascading rebase. Uses the same combined condition.
- Both functions set `result.NeedsSubmit` / show the "run submit" message
only when the flag is true.
**`internal/tui/modifyview/types.go`**
- Added `NeedsSubmit bool` to `ApplyResult` so the caller can use it
for the success message.
**`cmd/modify.go`**
- `printModifySuccess` now takes its cue from `result.NeedsSubmit`
instead of `s.ID != ""`. The "run `gh stack submit`" hint is only
shown when PR branches were actually affected.
**`internal/modify/apply_test.go`**
- Updated `TestApplyPlan_PendingSubmitForRemoteStack` to use branches
with PRs and trigger an actual rebase, validating the pending-submit
path correctly.
- Added `TestApplyPlan_ClearsStateForRemoteStackWithNoPRBranches`:
remote stack where no branches have PRs → state is cleared.
- Added `TestApplyPlan_PendingSubmitOnlyWhenPRBranchesAffected`:
remote stack with a mix of PR and non-PR branches, only the non-PR
branch is renamed → state is cleared, `NeedsSubmit` is false.
## Behavior summary
| Scenario | Before | After |
|---|---|---|
| Modify on local stack (no remote ID) | State cleared | State cleared (unchanged) |
| Modify on remote stack, PR branches affected | `PhasePendingSubmit` | `PhasePendingSubmit` (unchanged) |
| Modify on remote stack, only local branches affected | `PhasePendingSubmit` ❌ | State cleared ✅ |
The `CheckStateGuard` function (used by `add`, `push`, `sync`, `unstack`,
`rebase`) already did not block on `PhasePendingSubmit`, so those commands
are unaffected by this change.
* clear state after saving stack
* clarify submit requirement in description
* assign value directly
* swtich to nearest surviving branch after modify
After `gh stack modify` applies changes, the user may end up on an
orphaned branch that is no longer part of the stack — for example, if
their checked-out branch was dropped, folded into another branch, or
renamed. Previously, the code blindly restored the original branch
regardless of whether it still existed in the stack.
Add a `resolveCheckoutBranch` helper that inspects the modify plan and
the post-modify stack to determine the best branch to check out:
1. Still in stack → keep the original branch (no-op)
2. Renamed → check out the new name
3. Folded down → check out the fold target (branch below)
4. Folded up → check out the fold target (branch above)
5. Dropped → check out the nearest surviving neighbor
(prefer above, fall back to below)
6. Fallback → topmost branch in the stack
Both `ApplyPlan` and `ContinueApply` (the `--continue` path) now use
this helper instead of unconditionally restoring the original branch.
When the resolved branch differs from the original, a message is
printed so the user knows they've been switched.
The resolution uses the pre-modify snapshot (already persisted in the
state file) to determine original adjacency, so it works correctly even
when multiple branches are removed in the same operation.
Includes 12 new tests:
- 9 unit tests for resolveCheckoutBranch covering all action types,
edge cases (topmost dropped, multiple drops, empty stack), and
the fallback path
- 3 integration tests verifying ApplyPlan checks out the correct
branch after drop, fold-down, and rename operations
* handle CheckoutBranch errors
* handle renamed branches
* Allow `gh stack add` to adopt existing branches
Previously, `gh stack add` rejected any branch name that already existed
in git with a blanket "branch already exists" error. This was overly
restrictive — users who create branches ahead of time (e.g. from the
GitHub UI or via `git branch`) had no way to incorporate them into a
stack without deleting and recreating them.
Now, if the specified branch exists in git but is not part of any
existing stack, `add` adopts it: it skips branch creation, checks out
the existing branch, and appends it to the stack metadata. This mirrors
the adopt-or-create pattern already used by `gh stack init`.
Branches that belong to another stack are still rejected by the existing
`ValidateNoDuplicateBranch` guard, so there is no risk of cross-stack
conflicts.
Behavioral summary:
- Existing branch, not in any stack → adopted (checkout only, no create)
- Existing branch, already in a stack → error (unchanged)
- Non-existent branch → created (unchanged)
- Staging/commit flags (-A, -u, -m) work with adopted branches
Tests added:
- TestAdd_AdoptsExistingBranch
- TestAdd_RejectsExistingBranchInStack
- TestAdd_AdoptsExistingBranchWithCommit
* assert for runAdd err in test
* include prefix in branch name input
* custom prompter with colored input text
* minor fix: arrow direction for initialized stack
* fix comment
* handle SetTermMode err
* Add --committer-date-is-author-date flag to gh stack rebase
Introduce an opt-in `--committer-date-is-author-date` flag (with
`--preserve-dates` alias) for `gh stack rebase`. The flag is passed
through to every underlying `git rebase` invocation in the cascade,
keeping committer dates equal to author dates so that identical content
rebased onto an identical parent produces stable SHAs. This reduces
spurious force-push notifications and noisy review timelines, especially
in deep stacks where bottom branches get re-rebased on every merge.
Git layer changes:
- Add `RebaseOpts` struct with `CommitterDateIsAuthorDate` field to
`internal/git/gitops.go`
- Update `Ops` interface, `defaultOps`, public wrappers, and
`rebaseContinueOnce`/`tryAutoResolveRebase` helpers to accept and
forward the flag
- Update `MockOps` to match the new signatures
Command layer changes:
- Register `--committer-date-is-author-date` and `--preserve-dates`
flags on the cobra command in `cmd/rebase.go`
- Add `CommitterDateIsAuthorDate` to `cascadeRebaseOpts` and thread it
to all `git.Rebase`/`git.RebaseOnto` calls in `cmd/utils.go`
- Persist the flag in `rebaseState` JSON so `--continue` resumes with
the same behavior; pass it to `RebaseContinue` and subsequent cascade
calls
- Update `internal/modify/apply.go` callers to pass zero-value
`RebaseOpts{}`
Tests:
- Update all existing mock signatures in rebase, sync, and modify tests
- Add tests for flag passthrough, `--preserve-dates` alias, state
round-trip, `--continue` flag restoration, and conflict state
persistence
Docs:
- Update flag tables and examples in README.md and
docs/src/content/docs/reference/cli.md
* clearer wording in docs and help text
* fix: sync performs cascade rebase even when trunk is already up-to-date
Previously, `gh stack sync` gated the cascade rebase on whether trunk
or stack branches were fast-forwarded during the current run. This meant
that if the user had already updated trunk locally (e.g., `git pull`),
sync would skip the rebase entirely even though stack branches hadn't
been rebased onto the current trunk.
This change:
- Adds `stackNeedsRebase()` to detect stale branches regardless of
whether trunk was updated in this run
- Extracts shared helpers (`fastForwardTrunk`, `cascadeRebase`,
`resolveOriginalRefs`) from duplicated code in sync.go and rebase.go
into utils.go, reducing ~450 lines of duplication
- Fixes rebase.go to skip queued branches (was only skipping merged),
consistent with sync's behavior via `IsSkipped()`
- Refactors rebase --continue to reuse the shared cascade helper
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* address review feedback: error handling and index validation
- resolveOriginalRefs now returns (map, error) instead of silently
swallowing RevParseMap failures; sync warns and skips rebase, rebase
aborts with a clear error
- cascadeRebase uses a new Err field on the result struct to distinguish
fatal errors (e.g. checkout failure) from recoverable conflicts;
callers no longer enter conflict-recovery flow for non-conflict errors
- continueRebase validates that remaining branch indices are contiguous
in stack order, erroring out if the stack was reordered between
conflict and --continue
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* prune merged branches
* interactively prompt for prune
* delete remote tracking ref too
* disable selecting merged branches in TUIs
* include full list (including merged PRs) in PUT request to stacks API
* add prune to docs
* addressing review comments
* increment skill file version
- Deduplicate API calls: syncStackPRs now returns PRDetails for
LoadBranchNodes to reuse, eliminating redundant FindPRDetailsForBranch calls
- Parallelize API calls in syncStackPRs (capped at 6 concurrent requests)
- Parallelize git operations in LoadBranchNodes (capped at 4 concurrent)
- Show "Loading stack..." indicator for interactive sessions
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Audit all 7 GraphQL operations and remove fields that are fetched but
never used in Go code:
- Remove FindAnyPRForBranch: entire function is dead code (zero call sites)
- FindPRForBranch: remove title, state, headRefName, merged (4 fields)
- CreatePR: remove title, state, headRefName, baseRefName, isDraft (5 fields)
- FindPRDetailsForBranch: remove id, title, headRefName, baseRefName,
comments { totalCount } (4 fields + 1 nested object)
- FindPRByNumber: remove title (1 field)
Also remove Title from PullRequest struct, and Title + CommentsCount
from PRDetails struct since they are no longer populated or read.
Total: ~15 unused fields removed across 5 queries, 1 dead query deleted,
and 1 unnecessary nested object (comments) eliminated.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* run fetch before push operations
* ignore if ref doesn't exist on remote
* rm fetch from link
* more durable fetch by trying all first and falling back to individual fetches
* run fetch before sync
* git primitives for modify cmd
* extract reusable TUI parts
* modify cmd
* recreate stack after modify
* add checks to prevent other modifications while modify is applying
* modify continue for resuming after resolving conflicts
* fix bug with duplicate stack entries after modifying
* reuse conflict resolution help msg from rebase
* additional confirmation before overwriting stack on remote
* fix recreate order of operations
Co-authored-by: Copilot <copilot@github.com>
* move base commit instead of cherry picking for fold up
* check to ensure we aren't left with zero branches
* unify and dedupe across view and modify tui
* more detailed help instructions
Co-authored-by: Copilot <copilot@github.com>
* only recommend submit if stack exists on remote
Co-authored-by: Copilot <copilot@github.com>
* tests for modify tui, apply modifications, submit modifications
* refactor submit for regular and pending modifications
* rename recover to abort
Co-authored-by: Copilot <copilot@github.com>
* docs for modify cmd
* tui styling updates
* updated tui screenshot
* addressing review comments
* Fix 4 bugs from code review
Bug 1: Move RevParseMap error check before using originalRefs.
The error from git.RevParseMap() was deferred past iteration of
originalRefs, which could panic on a nil map.
Bug 2: Differentiate cherry-pick vs rebase conflicts in modify.
Cherry-pick conflicts don't save state as 'conflict' phase, so
--continue won't work. Now prints --abort-only instructions for
cherry-pick conflicts.
Bug 3: Unwind now cleans up branches created by renames.
After restoring snapshot branches, Unwind deletes renamed branch
names that don't belong to the original snapshot.
Bug 4: Simplify push message in submit command.
Changed from 'Pushing N branches to remote...' to 'Pushing to
remote...' since individual branches may fail.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix 7 nit issues from code review
11: Add named constants for phase strings (PhaseApplying, PhaseConflict,
PhasePendingSubmit) in state.go; replace remaining raw literals in
state.go CheckStateGuard.
14: Fix bottomLines comment mismatch — listed 3 items but value is 2.
15: Extract magic number 88 to MinWidthForArt constant in header.go.
16: Remove unused stackview import anchor in model.go — the import
is used via types.go where BranchNode is embedded.
17: Simplify CheckStackLinearity parent resolution — ActiveBaseBranch
already handles skipping merged branches.
18: Fix rename undo matching any rename — add NewName check so only
the specific rename being undone is matched.
20: Add TestUndoRename and TestUndoRename_DoesNotAffectOtherRenames
to validate rename undo behavior.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Make cherry-pick conflicts recoverable via --continue
Previously, cherry-pick conflicts during fold-down operations could only
be resolved with --abort. Now they save full conflict state (phase,
conflict type, fold branch/target, remaining branches) to the state file,
enabling recovery via 'gh stack modify --continue'.
Changes:
- Add ConflictType field to StateFile (rebase or cherry_pick)
- Add FoldBranch/FoldTarget fields for cherry-pick context
- Add CherryPickContinue to git package (cherry-pick --continue)
- Save cherry-pick conflict state in ApplyPlan with remaining branches
- ContinueApply handles both rebase and cherry-pick conflicts
- Unified conflict messaging in cmd/modify.go (both types show --continue)
- Updated test to verify cherry-pick conflict state is saved correctly
* Apply suggestions from code review
Co-authored-by: Luke Ghenco <lukeghenco@github.com>
Co-authored-by: Sameen Karim <skarim@github.com>
---------
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Luke Ghenco <lukeghenco@github.com>
* switch cmd to interactively switch to another branch in the stack
* add switch to docs
* addressing review comments
* bump skill file version
* default to current branch
* backfill ontoOldBase for deleted merged branches
* ensure upstack rebase checks immediate predecessor
* fix for stale ontoOldBase causing rebase conflicts
Sameen Karim