{"thread":{"id":"66406","subject":"[RFC] git stash: add porcelain for sharing stashes through remotes","startedAt":"2026-09-28T14:27:35Z","lastAt":"2026-10-05T15:25:38Z","messageCount":8,"participants":["Hanan Arshad","brian m. carlson","Johannes Sixt","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"553479","messageId":"CAKPibBw2XxjGpE_DZrWLZmMHs7kAyvOaP8504kfoh61c4UkGyg@mail.gmail.com","threadId":"66406","inReplyTo":null,"subject":"[RFC] git stash: add porcelain for sharing stashes through remotes","fromName":"Hanan Arshad","fromEmail":"hananarshad619@gmail.com","sentAt":"2026-09-28T14:27:23Z","receivedAt":"2026-09-28T14:27:35Z","isPatch":false,"body":"Hi,\n\nI'd like to propose adding a small porcelain workflow for sharing\nstashes through a Git remote.\n\ngit stash export and git stash import already provide a transportable\nrepresentation of stashes. I tested the following workflow using\nexisting commands:\n\nAlice:\n  git stash export --print stash@{0}\n  git push origin <export-tip>:refs/stashes/alice/wip\n\nBob:\n  git fetch origin refs/stashes/alice/wip:refs/shared-stashes/origin/alice/wip\n  git stash import refs/shared-stashes/origin/alice/wip\nThe imported stash is a normal local stash and retains the original\nstash object ID. Removing the remote ref afterward does not affect\nBob's imported stash.\n\nI'd like to add porcelain around this existing mechanism for four operations:\n\n1- publish a selected stash to a remote\n2- list available shared stashes\n3- get a shared stash as a normal local stash\n4- remove a shared stash from the remote\n\nThis would not introduce a new stash object format, server-side\nservice, or synchronization model. It would essentially compose the\nexisting export/import mechanism with normal push/fetch operations.\nBefore working on an implementation, I'd appreciate feedback on a few\ndesign points:\n1- What remote ref namespace would be appropriate?\n2- Should shared stashes use an explicit user-provided name or an\nobject-derived identifier?\n3- Should listing only inspect remote refs, or fetch the export\ncommits so stash messages can also be displayed?\n4- What command naming would fit best with the existing git stash interface?\n\nIf the general direction seems reasonable, I can follow up with a more\nconcrete interface and implementation.\n\nThanks,\nHanan Arshad\n"},{"id":"553651","messageId":"arw5XxJPNlUxU8TS@fruit.crustytoothpaste.net","threadId":"66406","inReplyTo":"CAKPibBw2XxjGpE_DZrWLZmMHs7kAyvOaP8504kfoh61c4UkGyg@mail.gmail.com","subject":"Re: [RFC] git stash: add porcelain for sharing stashes through remotes","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2026-09-29T22:19:12Z","receivedAt":"2026-09-29T22:19:15Z","isPatch":false,"body":"On 2026-09-28 at 14:27:23, Hanan Arshad wrote:\n> Hi,\n> \n> I'd like to propose adding a small porcelain workflow for sharing\n> stashes through a Git remote.\n> \n> git stash export and git stash import already provide a transportable\n> representation of stashes. I tested the following workflow using\n> existing commands:\n> \n> Alice:\n>   git stash export --print stash@{0}\n>   git push origin <export-tip>:refs/stashes/alice/wip\n\nYou can also use `--to-ref`, which is what I use, and then push that.\n\n> Bob:\n>   git fetch origin refs/stashes/alice/wip:refs/shared-stashes/origin/alice/wip\n>   git stash import refs/shared-stashes/origin/alice/wip\n> The imported stash is a normal local stash and retains the original\n> stash object ID. Removing the remote ref afterward does not affect\n> Bob's imported stash.\n> \n> I'd like to add porcelain around this existing mechanism for four operations:\n> \n> 1- publish a selected stash to a remote\n> 2- list available shared stashes\n> 3- get a shared stash as a normal local stash\n> 4- remove a shared stash from the remote\n\nI think that at least 1 is useful here, but you're going to need some\nsort of customization.  The name I use for stashes when I am the only\nperson on the remote is not the same name I use when I'm sharing a\nremote with others at my employer.\n\n2 is going to be hard because you don't know whether a ref is a stash\nwithout downloading the data.  3 is also hard because there's no\nstandard namespacing and it's going to differ based on the context (such\nas refs/heads/bk2204/stash or refs/heads/stash).  4 isn't that\ndifficult.\n\n> This would not introduce a new stash object format, server-side\n> service, or synchronization model. It would essentially compose the\n> existing export/import mechanism with normal push/fetch operations.\n> Before working on an implementation, I'd appreciate feedback on a few\n> design points:\n> 1- What remote ref namespace would be appropriate?\n\nAgain, this is going to depend on the user and environment.\n\n> 2- Should shared stashes use an explicit user-provided name or an\n> object-derived identifier?\n\nNames are going to be nicer.  We don't require people to memorize object\nIDs and allow them to use branch and tag names.\n\n> 3- Should listing only inspect remote refs, or fetch the export\n> commits so stash messages can also be displayed?\n\nStashes can be large because they (a) can contain untracked files and\n(b) contain a reference to history, so inspecting only remote refs is\ngoing to be a lot lighter.\n\n> 4- What command naming would fit best with the existing git stash interface?\n\nProbably `git stash push` or something like that.\n\nI think some nicer tooling would be helpful, so I'm in favour of that,\nbut I'm not sure that standardization is going to be possible.\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"554142","messageId":"20261005055337.7579-1-hananarshad619@gmail.com","threadId":"66406","inReplyTo":"arw5XxJPNlUxU8TS@fruit.crustytoothpaste.net","subject":"Re: [RFC] git stash: add porcelain for sharing stashes through remotes","fromName":"Hanan Arshad","fromEmail":"hananarshad619@gmail.com","sentAt":"2026-10-05T05:53:37Z","receivedAt":"2026-10-05T05:53:42Z","isPatch":false,"body":"Hi Brian,\n\nThanks 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.\n\nI agree that Git should not impose a fixed namespace such as:\n\nrefs/stashes/<author>/<name>\n\nInstead, the remote ref should be explicitly chosen by the user. For example:\n\nrefs/stashes/hanan/fix-login\nrefs/stashes/fix-login\nrefs/heads/hanan/stash\nrefs/heads/stash\n\nThe tooling would provide the stash transport workflow without standardizing where the remote stores it.\n\nThe revised interface I have in mind is:\n\nPublish one stash to a user-selected remote ref:\n\ngit stash publish <remote> <remote-ref> [<stash>]\n\nFor example:\n\ngit stash publish origin refs/stashes/hanan/fix-login stash@{0}\n\nIf <stash> is omitted, stash@{0} would be used.\n\nInternally this would reuse the existing stash export mechanism and normal push machinery. The original local stash would remain unchanged.\n\nList matching remote refs without downloading their objects:\n\ngit stash list --remote <remote> [<ref-pattern>]\n\nFor example:\n\ngit stash list --remote origin 'refs/stashes/*'\n\nThis 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.\n\nRetrieve one or more stashes from remote refs:\n\ngit stash get <remote> <remote-ref>\ngit stash get <remote> <ref-pattern>\n\nA single ref retrieves one stash:\n\ngit stash get origin refs/stashes/hanan/fix-login\n\nAn explicit pattern could retrieve multiple stashes:\n\ngit stash get origin 'refs/stashes/hanan/*'\n\nEach matching ref would be fetched and passed through the existing stash import logic, producing normal local stash entries.\n\nPrefix matching would not be implicit. For example:\n\ngit stash get origin refs/stashes/hanan\n\nwould refer only to that exact ref. The user would need to specify refs/stashes/hanan/* to retrieve refs below that namespace.\n\nNo tracking relationship would be established between the imported local stashes and the remote refs.\n\nRemove one or more shared stashes by deleting their remote refs:\n\ngit stash remove <remote> <remote-ref>\ngit stash remove <remote> <ref-pattern>\n\nA single ref:\n\ngit stash remove origin refs/stashes/hanan/fix-login\n\nMultiple refs:\n\ngit stash remove origin 'refs/stashes/hanan/*'\n\nAgain, wildcard matching would need to be explicit rather than treating a ref prefix as a namespace automatically.\n\nThis would use the normal remote ref deletion mechanism. Existing local copies would remain unaffected.\n\npublish 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.\n\nHuman-readable ref names would be used rather than requiring users to work with object IDs.\n\nThe overall implementation would remain:\n\nlocal stash\n    -> stash export\n    -> push to user-selected remote ref\n    -> fetch\n    -> stash import\n    -> normal local stash\n\nSo the proposal would add porcelain around the existing mechanisms without imposing a universal remote stash namespace.\n\nDoes this direction address your concern about standardization?\n\nAlso, 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?\n\nThanks,\nHanan Arshad\n"},{"id":"554150","messageId":"e1635b9c-bc03-4835-805f-5fa52f09364d@kdbg.org","threadId":"66406","inReplyTo":"20261005055337.7579-1-hananarshad619@gmail.com","subject":"Re: [RFC] git stash: add porcelain for sharing stashes through remotes","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2026-10-05T07:47:20Z","receivedAt":"2026-10-05T07:47:29Z","isPatch":false,"body":"Am 05.10.26 um 07:53 schrieb Hanan Arshad:\n> The revised interface I have in mind is:\n> \n> Publish one stash to a user-selected remote ref:\n> \n> git stash publish <remote> <remote-ref> [<stash>]\n\nI am actually not very happy with such an interface. The premise to have\nit is that stashes are something that can (and should) be shared with\nother people. But this is not the case. Stashes are strictly personal,\nshort-lived, work-in-progress-not-worth-to-be-committed states. If you\nuse stashes for longer-lived, worth-to-be-committed, sharable project\nstates, then you are doing something wrong. You should be using branch\nlabels instead.\n\n> \n> For example:\n> \n> git stash publish origin refs/stashes/hanan/fix-login stash@{0}\n> \n> If <stash> is omitted, stash@{0} would be used.\n> \n> Internally this would reuse the existing stash export mechanism and\n> normal push machinery. The original local stash would remain unchanged.\n\nThere you have it. If a stash is worth to be shown, then do take the\nlong way via `git stash export`, and push the ref. Or just do\n\n  git push origin stash@{0}:refs/stashes/hanan/fix-login\n\nThere's no magic support needed (nor, IMHO, desired).\n\n-- Hannes\n\n"},{"id":"554153","messageId":"CAKPibBx6364BcB2nqyQ7jhTaQMaUuR2TNKzZ-9H8VopcRjXbZw@mail.gmail.com","threadId":"66406","inReplyTo":"e1635b9c-bc03-4835-805f-5fa52f09364d@kdbg.org","subject":"Re: [RFC] git stash: add porcelain for sharing stashes through remotes","fromName":"Hanan Arshad","fromEmail":"hananarshad619@gmail.com","sentAt":"2026-10-05T08:03:44Z","receivedAt":"2026-10-05T08:03:45Z","isPatch":false,"body":"Hi Hannes,\n\nThanks for the feedback.\n\nI agree that stashes should remain short-lived WIP and that this\nshould not encourage using them as a replacement for branches or\nnormal project history.\n\nThe use case I have in mind is narrower: temporarily handing off an\nunfinished working state to another clone or developer, without first\nturning that state into a normal branch workflow.\n\nThe motivation is somewhat similar to a Perforce shelf from a UX\nperspective: the work is still temporary and unfinished, but another\ndeveloper may need to inspect, reproduce, test, or continue that exact\nstate.\n\nI also agree that Git already has the underlying mechanisms. In fact,\nthat is the main reason I thought this might make sense as porcelain\nrather than as a new feature model.\n\nToday this can already be done through existing refs and stash\ntransport mechanisms, for example with git stash export, git push, git\nfetch, and git stash import, or with the direct push example you\nmentioned.\n\nSo I am not proposing a new stash representation, server-side storage\nmodel, synchronization mechanism, or ownership model. The intent is\nonly to make an already possible operation easier to discover and\nperform correctly.\n\nThe question I am trying to answer is therefore not really \"should\nstashes become collaborative objects?\", but rather:\n\nIs there value in providing a small convenience command around an\nalready-supported stash transport workflow, so users do not have to\nunderstand and manually compose the lower-level ref/export/import\nsteps?\n\nI also think your comment suggests that keeping the scope very small\nwould be preferable. For example, rather than trying to introduce a\nlarger shared-stash subsystem, an initial version could potentially be\nlimited to a single publishing convenience and leave listing,\nfetching, deletion, etc. to existing Git commands.\n\nWould you still object to such a narrowly scoped porcelain wrapper, or\nis your concern mainly about introducing the broader concept of\n\"shared stashes\" into Git?\n\nThanks,\nHanan\n\nOn Mon, 5 Oct 2026 09:47:20 +0200, Johannes Sixt <j6t@kdbg.org> wrote:\n> Am 05.10.26 um 07:53 schrieb Hanan Arshad:\n> > The revised interface I have in mind is:\n> >\n> > Publish one stash to a user-selected remote ref:\n> >\n> > git stash publish <remote> <remote-ref> [<stash>]\n>\n> I am actually not very happy with such an interface. The premise to have\n> it is that stashes are something that can (and should) be shared with\n> other people. But this is not the case. Stashes are strictly personal,\n> short-lived, work-in-progress-not-worth-to-be-committed states. If you\n> use stashes for longer-lived, worth-to-be-committed, sharable project\n> states, then you are doing something wrong. You should be using branch\n> labels instead.\n>\n> >\n> > For example:\n> >\n> > git stash publish origin refs/stashes/hanan/fix-login stash@{0}\n> >\n> > If <stash> is omitted, stash@{0} would be used.\n> >\n> > Internally this would reuse the existing stash export mechanism and\n> > normal push machinery. The original local stash would remain unchanged.\n>\n> There you have it. If a stash is worth to be shown, then do take the\n> long way via `git stash export`, and push the ref. Or just do\n>\n> git push origin stash@{0}:refs/stashes/hanan/fix-login\n>\n> There's no magic support needed (nor, IMHO, desired).\n>\n> -- Hannes\n"},{"id":"554155","messageId":"7012706b-516b-4cd9-abf3-0144093e0779@kdbg.org","threadId":"66406","inReplyTo":"CAKPibBx6364BcB2nqyQ7jhTaQMaUuR2TNKzZ-9H8VopcRjXbZw@mail.gmail.com","subject":"Re: [RFC] git stash: add porcelain for sharing stashes through remotes","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2026-10-05T08:21:03Z","receivedAt":"2026-10-05T08:55:14Z","isPatch":false,"body":"Am 05.10.26 um 10:03 schrieb Hanan Arshad:\n> The use case I have in mind is narrower: temporarily handing off an\n> unfinished working state to another clone or developer, without first\n> turning that state into a normal branch workflow.\n\nUnderstood. But you don't do this ten times a day, so...\n\n> The question I am trying to answer is therefore not really \"should\n> stashes become collaborative objects?\", but rather:\n> \n> Is there value in providing a small convenience command around an\n> already-supported stash transport workflow, so users do not have to\n> understand and manually compose the lower-level ref/export/import\n> steps?\n\n... why do you need convenience? A simple export plus a push or even\njust a single push command are all that is required today.\n\nSo, IMHO, there is zero reason to upgrade stashes so that they can\nachieve the exact same thing that we can already do with branches.\n\n(Hence, if indeed you do share your half-finsihed work ten times a day,\nthen, please, by all means, use the right tool for the task: put your\nwork on a branch, not in a stash.)\n\n-- Hannes\n\n"},{"id":"554157","messageId":"CAKPibBwjRSb5cXd2iWo8bbYby1odcXNazEg-D9hcqbehrR6g3w@mail.gmail.com","threadId":"66406","inReplyTo":"7012706b-516b-4cd9-abf3-0144093e0779@kdbg.org","subject":"Re: [RFC] git stash: add porcelain for sharing stashes through remotes","fromName":"Hanan Arshad","fromEmail":"hananarshad619@gmail.com","sentAt":"2026-10-05T09:06:36Z","receivedAt":"2026-10-05T09:06:39Z","isPatch":false,"body":"Hi Hannes,\n\nThanks, I agree with your point after looking more closely at the\nexisting behavior.\n\nI had overstated what a git stash publish command would add. For a\nsingle stash, Git already handles the essential operation directly:\n\n    git push origin stash@{0}:refs/stashes/hanan/fix-login\n\nSo I agree that adding git stash publish would mostly duplicate\nfunctionality that already exists in one command, and I do not plan to\npursue it.\n\nThe narrower proposal I am considering now is only around the parts of\nthe temporary handoff workflow that are less convenient today:\n\n- discovering available remote stash refs,\n- fetching one and storing it as a normal local stash entry,\n- removing the remote ref when it is no longer needed.\n\nPublishing would remain ordinary git push.\n\nFor example, conceptually:\n\n    git stash list --remote <remote> <ref-pattern>\n    git stash get <remote> <remote-ref>\n    git stash remove <remote> <remote-ref>\n\nThese would only be porcelain around existing ls-remote, fetch/stash\nstore, and remote ref deletion. There would still be no new stash\nrepresentation, server-side mechanism, tracking relationship, or\nmandatory namespace.\n\nI think this is a more accurate scope for the original shelf-like\nworkflow I had in mind.\n\nThanks,\nHanan\n\nOn Mon, 5 Oct 2026 10:21:03 +0200, Johannes Sixt <j6t@kdbg.org> wrote:\n> Am 05.10.26 um 10:03 schrieb Hanan Arshad:\n> > The use case I have in mind is narrower: temporarily handing off an\n> > unfinished working state to another clone or developer, without first\n> > turning that state into a normal branch workflow.\n>\n> Understood. But you don't do this ten times a day, so...\n>\n> > The question I am trying to answer is therefore not really \"should\n> > stashes become collaborative objects?\", but rather:\n> >\n> > Is there value in providing a small convenience command around an\n> > already-supported stash transport workflow, so users do not have to\n> > understand and manually compose the lower-level ref/export/import\n> > steps?\n>\n> ... why do you need convenience? A simple export plus a push or even\n> just a single push command are all that is required today.\n>\n> So, IMHO, there is zero reason to upgrade stashes so that they can\n> achieve the exact same thing that we can already do with branches.\n>\n> (Hence, if indeed you do share your half-finsihed work ten times a day,\n> then, please, by all means, use the right tool for the task: put your\n> work on a branch, not in a stash.)\n>\n> -- Hannes\n"},{"id":"554187","messageId":"xmqqzewsmaod.fsf@gitster.g","threadId":"66406","inReplyTo":"CAKPibBwjRSb5cXd2iWo8bbYby1odcXNazEg-D9hcqbehrR6g3w@mail.gmail.com","subject":"Re: [RFC] git stash: add porcelain for sharing stashes through remotes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-10-05T15:25:38Z","receivedAt":"2026-10-05T15:25:38Z","isPatch":false,"body":"Hanan Arshad <hananarshad619@gmail.com> writes:\n\n> The narrower proposal I am considering now is only around the parts of\n> the temporary handoff workflow that are less convenient today:\n>\n> - discovering available remote stash refs,\n> - fetching one and storing it as a normal local stash entry,\n> - removing the remote ref when it is no longer needed.\n\nFWIW, I agree with j6t.  Quoting the part you left at the bottom of\nyour message (by the way, please do not top-post on this list.  You\nquote what others said first, and then you write your response below\nthat):\n\n>> So, IMHO, there is zero reason to upgrade stashes so that they can\n>> achieve the exact same thing that we can already do with branches.\n>>\n>> (Hence, if indeed you do share your half-finsihed work ten times a day,\n>> then, please, by all means, use the right tool for the task: put your\n>> work on a branch, not in a stash.)\n\nAll of the three you listed (discovery, transfer, clean-up) become\neasier to work with if you used branches, branches have always had\ngood support for these three (and other) operations, and I do not\nsee a good reason to add a parallel support to do something similar.\n\n\n"}]}