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

From: Hanan Arshad <hananarshad619@gmail.com>
Date: Oct 5, 2026, 09:06 UTC
Message-ID: <CAKPibBwjRSb5cXd2iWo8bbYby1odcXNazEg-D9hcqbehrR6g3w@mail.gmail.com>
In-Reply-To: <7012706b-516b-4cd9-abf3-0144093e0779@kdbg.org>

Hi Hannes,

Thanks, I agree with your point after looking more closely at the existing behavior.

I had overstated what a git stash publish command would add. For a single stash, Git already handles the essential operation directly:

    git push origin stash@{0}:refs/stashes/hanan/fix-login

So I agree that adding git stash publish would mostly duplicate functionality that already exists in one command, and I do not plan to pursue it.

The narrower proposal I am considering now is only around the parts of the temporary handoff workflow that are less convenient today:

- discovering available remote stash refs,
- fetching one and storing it as a normal local stash entry,
- removing the remote ref when it is no longer needed.

Publishing would remain ordinary git push.

For example, conceptually:

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

These would only be porcelain around existing ls-remote, fetch/stash store, and remote ref deletion. There would still be no new stash representation, server-side mechanism, tracking relationship, or mandatory namespace.

I think this is a more accurate scope for the original shelf-like workflow I had in mind.

Thanks, Hanan

On Mon, 5 Oct 2026 10:21:03 +0200, Johannes Sixt <j6t@kdbg.org> wrote:

Show 26 quoted lines

> Am 05.10.26 um 10:03 schrieb Hanan Arshad:
> > The use case I have in mind is narrower: temporarily handing off an
> > unfinished working state to another clone or developer, without first
> > turning that state into a normal branch workflow.
>
> Understood. But you don't do this ten times a day, so...
>
> > The question I am trying to answer is therefore not really "should
> > stashes become collaborative objects?", but rather:
> >
> > Is there value in providing a small convenience command around an
> > already-supported stash transport workflow, so users do not have to
> > understand and manually compose the lower-level ref/export/import
> > steps?
>
> ... why do you need convenience? A simple export plus a push or even
> just a single push command are all that is required today.
>
> So, IMHO, there is zero reason to upgrade stashes so that they can
> achieve the exact same thing that we can already do with branches.
>
> (Hence, if indeed you do share your half-finsihed work ten times a day,
> then, please, by all means, use the right tool for the task: put your
> work on a branch, not in a stash.)
>
> -- Hannes