git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC] git stash: add porcelain for sharing stashes through remotes

From
Hanan Arshad <hananarshad619@gmail.com>
Date
Oct 5, 2026, 05:53 UTC
Message-ID
<20261005055337.7579-1-hananarshad619@gmail.com>
In-Reply-To
<arw5XxJPNlUxU8TS@fruit.crustytoothpaste.net>
Hi Brian,
Thanks for the detailed feedback. I reconsidered the design based on your comments, particularly the point that the appropriate remote namespace depends on the user and environment.
I agree that Git should not impose a fixed namespace such as:
refs/stashes/<author>/<name>
Instead, the remote ref should be explicitly chosen by the user. For example:

refs/stashes/hanan/fix-login refs/stashes/fix-login refs/heads/hanan/stash refs/heads/stash

The tooling would provide the stash transport workflow without standardizing where the remote stores it.
The revised interface I have in mind is:
Publish one stash to a user-selected remote ref:
git stash publish <remote> <remote-ref> [<stash>]
For example:
git stash publish origin refs/stashes/hanan/fix-login stash@{0}
If <stash> is omitted, stash@{0} would be used.
Internally this would reuse the existing stash export mechanism and normal push machinery. The original local stash would remain unchanged.
List matching remote refs without downloading their objects:
git stash list --remote <remote> [<ref-pattern>]
For example:
git stash list --remote origin 'refs/stashes/*'
This would list refs only rather than downloading each stash to obtain its description. As you pointed out, stashes may be large, so fetching their contents merely for listing would be unnecessarily expensive.
Retrieve one or more stashes from remote refs:

git stash get <remote> <remote-ref> git stash get <remote> <ref-pattern>

A single ref retrieves one stash:
git stash get origin refs/stashes/hanan/fix-login
An explicit pattern could retrieve multiple stashes:
git stash get origin 'refs/stashes/hanan/*'
Each matching ref would be fetched and passed through the existing stash import logic, producing normal local stash entries.
Prefix matching would not be implicit. For example:
git stash get origin refs/stashes/hanan
would refer only to that exact ref. The user would need to specify refs/stashes/hanan/* to retrieve refs below that namespace.
No tracking relationship would be established between the imported local stashes and the remote refs.
Remove one or more shared stashes by deleting their remote refs:

git stash remove <remote> <remote-ref> git stash remove <remote> <ref-pattern>

A single ref:
git stash remove origin refs/stashes/hanan/fix-login
Multiple refs:
git stash remove origin 'refs/stashes/hanan/*'
Again, wildcard matching would need to be explicit rather than treating a ref prefix as a namespace automatically.
This would use the normal remote ref deletion mechanism. Existing local copies would remain unaffected.
publish would always operate on one stash, while get and remove could operate on either a single remote ref or an explicitly specified set of matching refs.
Human-readable ref names would be used rather than requiring users to work with object IDs.
The overall implementation would remain:
local stash
    -> stash export
    -> push to user-selected remote ref
    -> fetch
    -> stash import
    -> normal local stash
So the proposal would add porcelain around the existing mechanisms without imposing a universal remote stash namespace.
Does this direction address your concern about standardization?
Also, do you think it makes sense to pursue all four operations as porcelain, or would you prefer starting with only git stash publish and leaving listing, retrieval, and removal to existing Git commands?

Thanks, Hanan Arshad

Previous: brian m. carlsonNext: Johannes Sixt
Message 3 of 10 in “[RFC] git stash: add porcelain for sharing stashes through remotes”
  1. Hanan ArshadSep 28, 2026
  2. brian m. carlsonSep 29, 2026
  3. Hanan ArshadOct 5, 2026
  4. Johannes SixtOct 5, 2026
  5. Hanan ArshadOct 5, 2026
  6. Johannes SixtOct 5, 2026
  7. Hanan ArshadOct 5, 2026
  8. Junio C HamanoOct 5, 2026
  9. Hanan ArshadOct 7, 2026
  10. Johannes SixtOct 7, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.