From: Hanan Arshad Date: Mon, 05 Oct 2026 08:03:44 GMT Subject: Re: [RFC] git stash: add porcelain for sharing stashes through remotes Message-ID: In-Reply-To: Hi Hannes, Thanks for the feedback. I agree that stashes should remain short-lived WIP and that this should not encourage using them as a replacement for branches or normal project history. 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. The motivation is somewhat similar to a Perforce shelf from a UX perspective: the work is still temporary and unfinished, but another developer may need to inspect, reproduce, test, or continue that exact state. I also agree that Git already has the underlying mechanisms. In fact, that is the main reason I thought this might make sense as porcelain rather than as a new feature model. Today this can already be done through existing refs and stash transport mechanisms, for example with git stash export, git push, git fetch, and git stash import, or with the direct push example you mentioned. So I am not proposing a new stash representation, server-side storage model, synchronization mechanism, or ownership model. The intent is only to make an already possible operation easier to discover and perform correctly. 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? I also think your comment suggests that keeping the scope very small would be preferable. For example, rather than trying to introduce a larger shared-stash subsystem, an initial version could potentially be limited to a single publishing convenience and leave listing, fetching, deletion, etc. to existing Git commands. Would you still object to such a narrowly scoped porcelain wrapper, or is your concern mainly about introducing the broader concept of "shared stashes" into Git? Thanks, Hanan On Mon, 5 Oct 2026 09:47:20 +0200, Johannes Sixt wrote: > Am 05.10.26 um 07:53 schrieb Hanan Arshad: > > The revised interface I have in mind is: > > > > Publish one stash to a user-selected remote ref: > > > > git stash publish [] > > I am actually not very happy with such an interface. The premise to have > it is that stashes are something that can (and should) be shared with > other people. But this is not the case. Stashes are strictly personal, > short-lived, work-in-progress-not-worth-to-be-committed states. If you > use stashes for longer-lived, worth-to-be-committed, sharable project > states, then you are doing something wrong. You should be using branch > labels instead. > > > > > For example: > > > > git stash publish origin refs/stashes/hanan/fix-login stash@{0} > > > > If 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. > > There you have it. If a stash is worth to be shown, then do take the > long way via `git stash export`, and push the ref. Or just do > > git push origin stash@{0}:refs/stashes/hanan/fix-login > > There's no magic support needed (nor, IMHO, desired). > > -- Hannes