Re: Subject: [RFC] stash: let the stash stack live in a configurable ref

On Sun, Aug 23, 2026, at 16:19, Vladimir Sitnikov wrote:
> refs/stash is shared by the main checkout and every linked worktree, so
> two worktrees push onto and pop from the same stack.  With git 2.52.0:
>
>     git init wt-a && cd wt-a
>     git commit --allow-empty -m base
>     git worktree add ../wt-b -b b
>
>     echo A >file-a && git add file-a
>     git stash push -m "worktree A: half-finished refactor"
>
>     cd ../wt-b
>     echo B >file-b && git add file-b
>     git stash push -m "worktree B: unrelated fix"
>     git stash pop      # worktree B's own entry, as expected
>     git stash pop      # worktree A's entry, applied here
>
> After the second pop, wt-b holds both file-a and file-b, and wt-a has an
> empty stash and a clean tree.  Nothing warned about it, and the entry is
> gone from the stack, so wt-a has no way to find out where its changes
> went.
>
> This is documented behavior: git-worktree(1) lists refs/bisect,
> refs/worktree and refs/rewritten as the per-worktree exceptions, and
> refs/stash is not among them.

Yes. Both the existing behavior and per-worktree stashes are useful in
the abstract:

• I sometimes make changes in the wrong worktree and then just push
  there and pop in the correct one. So it has practical uses. But it
  doesn’t feel like it jives with modern Git (Git 2015, when worktrees
  came). It does not feel elegant.
• Pushing and popping in isolation also makes sense and surely has just
  as many practical uses for people who both use worktrees and the stash
  compared to someone who only uses the stash.

If not for hysterical raisins, I think per-worktree would make sense as
the default. But with history in mind a configuration option makes the
most sense.

> For a human who drives one worktree at a
> time it is mostly harmless, and sharing is occasionally useful - stash
> in one worktree, apply in another, as a way to move work across
> checkouts.

I see the narrative crescendo in the first clause.

I don’t see how it is mostly harmless. Yes, it is useful, but it could
also be confusing because it IMO isn’t consistent with (again IMO)
modern Git with worktrees. So people might only get confused while using
Git all manually, stalling the current session and sending them to ask
SO/LLM; there is no massively parallel cluster of Git sessions going off
the rails as one automated entity creates a merge conflict that somehow
cascades and wastes many dollars.

But the bar for introducing configuration options for porcelain commands
for can’t-break-default has always been, my my knowledge, those lone
manual sessions that merely get stalled and leads to confusion in the
person operator. So this could be worth implementing just based on
that. (And it benefiting other cases is also great.)

>
> What changed is who runs these commands.

The reveal.

> Running one coding agent per
> worktree, against one repository, has become a common setup, and the
> agents stash and pop on their own schedule.  The failure above then
> turns into silent data movement between unrelated sessions.  The same
> report has already been filed against at least two such tools:
>
>     https://github.com/github/copilot-cli/issues/1725
>     https://github.com/stablyai/orca/issues/13695

To my uninformed, not-using-agents mind, what agents do with the tool
seems like the least concerning thing. They can be non-deterministically
instructed to not use the stash.

The stash has already been optional, something that you can achieve with
the other porcelain commands. So any code-changing entity can adapt to
not being allowed to use the stash.

And for determinism you can give them a git(1) wrapper that bans
git-stash(1).

>
> I would like to propose a configuration knob rather than a new concept,
> because most of the machinery is already in the tree:
>
>   - refs/worktree/* is per-worktree, so a private stack has somewhere
>     to live;
>   - `git stash export --to-ref` and `git stash import` already read and
>     write a stash stack under an arbitrary ref;
>   - extensions.worktreeConfig and `git config --worktree` already give
>     a worktree its own configuration.
>
> The missing piece is telling stash itself which ref to use.  Say
> stash.ref, defaulting to refs/stash, honored by push, save, list,
> show, pop, apply, drop, branch and clear.  A worktree that wants
> isolation then asks for it once:
>
>     git config extensions.worktreeConfig true
>     git config --worktree stash.ref refs/worktree/stash

Opting in to `refs/worktree/stash` makes sense.

>[snip]
>   - Reachability.  fsck and reflog expiry learned to iterate
>     per-worktree refs, and I would like a second opinion on whether
>     stash entries under refs/worktree/* are safe from gc in the same
>     way refs/stash entries are.

See gitdatamodel(7).

    Git may delete objects that aren’t "reachable" from any reference or
    reflog.

Any particular ref namespace is not special with regards to
reachability and GC.

>[snip]