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

[Hanan Arshad <hananarshad619@gmail.com>]

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