You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a stack branch is checked out in a linked git worktree,
`git checkout` fails, blocking `restack` and `sync`. The new
`--worktrees` flag detects linked worktrees up front and rebases
those branches directly in their worktree directories instead.
- Add `ListWorktrees`, `RebaseHere`, `RebaseOntoHere`, and
`GetResolvedGitDir` to `internal/git`
- Fix `IsRebaseInProgress` to use resolved git dir (works in
linked worktrees where `.git` is a file, not a directory)
- Persist worktree map in `CascadeState` so `continue`/`abort`
operate on the correct worktree after conflicts
- Wrap worktree-related failures with actionable error messages
- Add unit tests, E2E tests, and README documentation
Closes#33
|`--worktrees`| Rebase branches checked out in linked worktrees in-place |
328
330
329
331
### undo
330
332
@@ -349,6 +351,26 @@ Snapshots are stored in `.git/stack-undo/` and archived to `.git/stack-undo/done
349
351
|`--force`| Skip confirmation prompt |
350
352
|`--dry-run`| Show what would be restored without doing it |
351
353
354
+
## Working with Git Worktrees
355
+
356
+
If you use [git worktrees](https://git-scm.com/docs/git-worktree) to check out multiple stack branches simultaneously, `git checkout` will refuse to switch to a branch that's already checked out in another worktree. This means `restack` and `sync` will fail when they try to check out those branches.
357
+
358
+
The `--worktrees` flag solves this. When set, **gh-stack** detects linked worktrees up front and rebases those branches directly in their worktree directories instead of checking them out:
359
+
360
+
```bash
361
+
# Restack with worktree-aware rebasing
362
+
gh stack restack --worktrees
363
+
364
+
# Sync with worktree-aware rebasing
365
+
gh stack sync --worktrees
366
+
```
367
+
368
+
If a rebase conflict occurs in a worktree branch, **gh-stack** will tell you which worktree directory to resolve it in. After resolving, run `gh stack continue` from the main repository as usual—**gh-stack** remembers which worktree the conflict lives in.
369
+
370
+
> [!NOTE]
371
+
>
372
+
> The `--worktrees` flag is opt-in. Without it, **gh-stack** behaves exactly as before. If none of your stack branches are checked out in linked worktrees, the flag is a harmless no-op.
373
+
352
374
## How It Works
353
375
354
376
**gh-stack** stores metadata in your local `.git/config`:
// Determine the starting node for branch collection
128
128
varstartNode*tree.Node
129
-
ifsubmitFromFlag=="HEAD" {
129
+
switch {
130
+
casesubmitFromFlag=="HEAD":
130
131
// --from without value: resolve to current branch (old behavior)
131
132
startNode=tree.FindNode(root, currentBranch)
132
133
ifstartNode==nil {
133
134
returnfmt.Errorf("branch %q is not tracked in the stack\n\nTo add it, run:\n gh stack adopt %s # to stack on %s\n gh stack adopt -p <parent> # to stack on a different branch", currentBranch, trunk, trunk)
0 commit comments