Feature request: spin up new wt that carries over uncommitted work

[jeremy0dell]

Hello again! I'm building a "fork" feature for my agentic dev environment on top of wt, and I'd love to try adding a wt step copy-working-tree that carries uncommitted work between worktrees as basically a sibling to wt step copy-ignored. Could maybe fold it into switch too, e.g. wt switch -create fix --carry. Open to the idea / the shape?

Examples:

 wt step copy-working-tree --from feature-a --to feature-b
 wt step copy-working-tree --from main --to fix --move

[worktrunk-bot]

Thanks for the suggestion, and for building on wt!

This is a good fit for a wt alias rather than a native subcommand. wt step copy-ignored exists because gitignored files are a filtered, opt-in set (.worktreeinclude patterns) that git itself won't move for you. Uncommitted tracked work is the opposite case — git stash already moves the staged/unstaged/untracked split atomically and (importantly) the stash lives in the shared .git, so it's reachable from any worktree of the repo. A native copy-working-tree would mostly be reimplementing stash, which is why worktrunk leans on an alias here.

The create-and-carry case you sketched (wt switch -create fix --carry) is already a documented recipe — move-changes:

# .config/wt.toml
[aliases]
move-changes = '''
if git diff --quiet HEAD && test -z "$(git ls-files --others --exclude-standard)"; then
  wt switch --create {{ to }} --execute="{{ args }}"
else
  git stash push --include-untracked --quiet
  wt switch --create {{ to }} --execute="git stash pop --index; {{ args }}"
fi
'''

wt move-changes --to=fix carries staged/unstaged/untracked into the new worktree (with the index split preserved via --execute="git stash pop --index"), and the guard skips the stash when nothing's in flight. To copy instead of move, swap the push for git stash apply --index --quiet. Anything after -- runs in the new worktree, e.g. wt move-changes --to=fix -- claude.

Your --from feature-a --to feature-b shape (between two existing worktrees, not create) isn't the shipped recipe, but it composes the same way since the stash is shared across worktrees — stash in the source, pop in the target. That's the manual form in the FAQ (How do I move uncommitted changes to a new worktree?); wrapping it in an alias with wt switch {{ to }} --execute=... gives you the existing→existing variant.

Docs for the extension points: aliases and tips & patterns.

If the alias doesn't cover a case you need, let us know the gap — a maintainer can weigh in on whether anything native is warranted.

[jeremy0dell]

@max-sixty @worktrunk-bot A global wt alias isn't really my preferred solution. I wrap wt as a dependency and my end users never run wt directly, so an alias means writing into each user's global config (or inlining the git myself). I'd rather call through wt than reach around it.

As an aside: stash apply/pop won't work here because they mutate the source worktree, and there's often an agent actively running in it. I keep things read-only instead by snapshotting into a temp index (read-tree HEAD → add -A → write-tree) and materializing that tree in the new worktree so the source is never touched.

With that in mind, this feels like a natural addition to wt, and I doubt my use case is unique. Right now it's ~130 lines of TS counting tests calling git atomics just to seed a worktree. That's why I'd love to see wt grow this capability :) But no worries if not, and also happy to give more context about what I'm building (I'm planning to release as OSS alpha very soon) if that helps

[worktrunk-bot]

Both of your objections land, and the earlier recipe doesn't cover them — thanks for spelling them out.

Read-only source. You're right that the stash recipe mutates the source: git stash push reverts the source working tree to HEAD, so an agent with in-flight work in that worktree would watch it disappear mid-operation. And the "to copy, swap push for apply" line in my earlier reply doesn't actually rescue that — you still have to push to create the stash before anything can apply it. Your temp-index snapshot (a throwaway GIT_INDEX_FILE, read-tree HEAD → add -A → write-tree, then materialize the tree in the target) never touches the source's index or working tree, which is the property the stash approach can't give you. That's the correct primitive for seeding a worktree while an agent runs in the source.

Distribution. Aliases resolve from project .config/wt.toml and user config, merged — but either layer is still config your wrapper has to inject into the user's environment, and since your users never invoke wt directly, an alias isn't a thing they'd call. A native subcommand is the one form you can drive through wt without reaching around it. That's a real gap, not something an alias closes.

So this isn't the niche-single-workflow case the alias deflection is meant for — a read-only "snapshot the source's working tree into a new/sibling worktree" primitive is something wt can express that git doesn't hand you directly (much like wt step copy-ignored for the gitignored set). Whether that warrants a native wt step is a design-acceptance call, and that's @max-sixty's to make, not mine — I'll leave the shape (and whether to reopen) to him. I've left your read-only mechanism and the wrapper constraint summarized above so it's on the record either way.

And yes — more context on what you're building would help frame it. If it's going OSS-alpha soon, a link to how it drives wt underneath would make the case concrete.

[max-sixty]

my main question with this sort of command is whether the surface area from the options means we're not encapsulating that much. for example, do we include staged changes? untracked ones?

I agree re the "don't use the global stage", that's nice

another option is the wt-foo extension — I agree it would be good to get things into wt if generally helpful — but also don't want wt to be getting in your way, and so these extension points should hopefully mean you can make progress, work with the ideas a bit, and then when they're working well, throw them over the wall to implement upstream...

[jeremy0dell]

wt definitely isn't getting in my way, it's a total force multiplier and I love it! I see the concern with surface area. I think a good starting place might be something narrower:

wt switch --create fix --base=@ --carry-snapshot

With NO knobs like --untracked, etc.

I was probably reaching for names that are too broad with copy-working-tree and --carry. --carry-snapshot OTOH feels explicit: take a read-only snapshot from the source worktree and seed the newly-created worktree with it. I also think this would place less burden on the future public API shape.

That keeps the first version modest. It would copy over the current non-ignored file contents, including untracked files, without trying to preserve the staged/unstaged split. Future knobs or step fns could be added if there's demand.

IMO this would handle the vast majority of wt consumers forking needs.

[max-sixty]

ok, yes. I agree it's possible that that satisfies all needs... but then also I can imagine that we only want to carry over the staged changes etc / a few other settings, and then we're doing API churn

I really think the best way of managing these cases is to implement it locally — with some typescript, or a tiny wt-foo extension (maybe also with some typescript...), and then wt's conservatism isn't slowing you down. I hope that's reasonable...

[jeremy0dell]

Totally reasonable, and I’ll defer to your judgment here. I’ve already got this implemented locally in my app, so I’m not blocked. Feel free to close this.

Separate from this ask, if you have time, I’m curious how you think about wt’s future shape: do you see it as roughly feature-complete and mostly in polish/conservatism mode, or are there areas you still expect to grow?

This thread made me wonder whether something like a future wt step copy ...args api could make sense someday, where copying state between worktrees is isolated and can afford the knobs you’re mentioning: staged-only, untracked, ignored, exact git state, etc. Not trying to reopen this request, more just curious where ideas like this should live long-term.

[max-sixty]

it's a good question. I don't think it's quite feature-complete; and I've been adding lots of things recently around the picker (PRs, much nicer UX courtesy of new skim releases, PR comments in previews, etc). I'm keen to find any "very contiguous" features like this, without broadening to a different area. And to continue round off corners.

I am cognizant to avoid config sprawl; I think often projects that reach this stage start adding lots of config options to cover every case, and then lose their simplicity for new users. If there are nice orthogonal features (like the recent addition of git configs in templates, or custom wt list columns), then that works well.

Also very open to any feedback!

[max-sixty]

will close for now but can return to it with more experience and wisdom...

[jeremy0dell]

Thanks Max! that makes sense about wanting to focus on continuous feature additions, I don't really have ideas or feedback other than forking because wt suits my needs very well.