Stash

The Stash tab in a worktree’s Git view (between History and Review) lists every stash in the repository and offers the usual lifecycle: inspect the diff, apply or pop, drop. In a worktree-first client you’ll reach for it less often than you’re used to — sometimes a fresh workspace is the better shelf.

The stash list

Each row shows the stash ref (stash@{0}, …), its short SHA, the message, and when it was created. Selecting a stash renders its diff in the diff pane, so you can check what a stash contains before touching it. Below the list:

• Apply — restores the stashed changes into the working tree and keeps the stash entry.
• Pop — restores the changes and removes the entry if the apply succeeds.
• Drop — deletes the selected stash without applying it.

If an apply or pop conflicts with your current working tree, Birch shows the git error in the tab and the affected files appear in the Changes tab flagged with the ⚡ conflict marker, with conflict markers in the files themselves. Resolve them there or in your editor — the conflict resolver window is aimed at merge, rebase, and cherry-pick conflicts and does not open for stash conflicts.

Creating a stash

Warning

There is currently no way to reach this feature in the shipped build — the menu that hosted it is hidden. It is documented here because the feature exists in the app and a new entry point is planned.

Birch’s stash dialog adds a Create new stash form to the same list: an optional message, Include untracked files, and Keep index (—keep-index) (stash the working tree but leave what you’ve already staged in place), plus a Show diff button for the selected stash.

Until the dialog gets a new entry point, create stashes from a terminal in the worktree — for example:

terminal

git stash push -m "wip: half-finished refactor"

Stashes created this way show up in the Stash tab immediately.

Stashes vs. worktrees

A stash parks changes so the same checkout can do something else. Birch’s worktree-first model offers a stronger version of the same move: if you’re interrupting real work rather than shelving an experiment, create a workspace for the new task instead. Your in-progress changes stay exactly where they are — no stash to remember, no conflicts when you pop it back — and the two lines of work can proceed (and be committed) independently.