Stashes

A stash is a saved snapshot of a change list’s pending work that you can keep for later, share, or move between machines.

Stashes are useful when you want to:

• pause work without submitting,
• switch to another task quickly,
• or share in-progress work for review/help without creating a branch.

Local vs. Remote Stashes

When you stash a change list, you can choose where it is stored:

• Local stash: stored on your machine (only you can see it).
• Remote stash: stored on the server (shareable, depending on permissions and stash access settings).

In general, use:

• Local stashes for personal “save points”.
• Remote stashes when you need to share work or move it between machines.

Remote stashes can also be a good backup option for work-in-progress: storing the stash on the server helps protect it from local machine loss while you’re not ready to submit.

What A Stash Contains

A stash captures:

• the list of pending file operations in the change list,
• the change list description,
• and metadata like tags (if you set them).

Attachments (Supporting Docs)

Stashes can include attachments: supporting files such as review notes, logs, telemetry, or build artifacts captured alongside the stashed work. This is a good way to share context with peers or to preserve data that an LLM can use later. See Attachments and Supporting Docs.

Stashes are not the same as a server branch: they don’t create a new repository history line. They are a way to save and restore workspace work-in-progress.

Stash Access Control (Remote Stashes)

Remote stashes can include access controls. There are two roles:

• Owners: can edit, add to, and delete stashes (can also retrieve them).
• Viewers: can retrieve stashes, but cannot modify or delete them.

These access lists may include users and/or groups (depending on what your server supports and how it’s configured).

Even if you can see a remote stash, repository access rules can still limit what you can do with its files after retrieval (for example, you might not be able to submit to a protected path).

Retrieving A Stash

Retrieving applies the stash back into your workspace (usually into a chosen change list).

If retrieving would overwrite existing pending operations or local file changes, the UI may prompt you to confirm and may offer to back up your current state into another stash first.

Stash Paths vs. Repository Paths (Sharing Requires Compatible Mappings)

When a stash captures file changes, it records files relative to the workspace root (the paths you see in your workspace tree).

This is convenient for sharing, but it also means two users generally need compatible repository links (repository maps) for the stash to apply cleanly:

• the stash expects the same local folder layout under the workspace root, and
• the workspace needs to be able to map each stashed path back to a repository entry in the current repository map.

If a stashed file path cannot be mapped onto your current workspace (because the repository map does not contain a compatible mapping), the UI indicates the problem by showing those stash files in red.

The workspace detects mismatches primarily by checking repository mapping for the path. It can be more lenient about the branch when determining whether a stash file “fits” into the current workspace.

Change List Revisions Use Stashes Internally

Change list local revisions are stored as local stashes internally, but they are treated as “change list revisions” and are hidden from the normal stash list.