All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Hanan Arshad <hananarshad619@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] git stash: add porcelain for sharing stashes through remotes
Date: Tue, 29 Sep 2026 22:19:12 +0000	[thread overview]
Message-ID: <arw5XxJPNlUxU8TS@fruit.crustytoothpaste.net> (raw)
In-Reply-To: <CAKPibBw2XxjGpE_DZrWLZmMHs7kAyvOaP8504kfoh61c4UkGyg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2895 bytes --]

On 2026-09-28 at 14:27:23, Hanan Arshad wrote:
> Hi,
> 
> I'd like to propose adding a small porcelain workflow for sharing
> stashes through a Git remote.
> 
> git stash export and git stash import already provide a transportable
> representation of stashes. I tested the following workflow using
> existing commands:
> 
> Alice:
>   git stash export --print stash@{0}
>   git push origin <export-tip>:refs/stashes/alice/wip

You can also use `--to-ref`, which is what I use, and then push that.

> Bob:
>   git fetch origin refs/stashes/alice/wip:refs/shared-stashes/origin/alice/wip
>   git stash import refs/shared-stashes/origin/alice/wip
> The imported stash is a normal local stash and retains the original
> stash object ID. Removing the remote ref afterward does not affect
> Bob's imported stash.
> 
> I'd like to add porcelain around this existing mechanism for four operations:
> 
> 1- publish a selected stash to a remote
> 2- list available shared stashes
> 3- get a shared stash as a normal local stash
> 4- remove a shared stash from the remote

I think that at least 1 is useful here, but you're going to need some
sort of customization.  The name I use for stashes when I am the only
person on the remote is not the same name I use when I'm sharing a
remote with others at my employer.

2 is going to be hard because you don't know whether a ref is a stash
without downloading the data.  3 is also hard because there's no
standard namespacing and it's going to differ based on the context (such
as refs/heads/bk2204/stash or refs/heads/stash).  4 isn't that
difficult.

> This would not introduce a new stash object format, server-side
> service, or synchronization model. It would essentially compose the
> existing export/import mechanism with normal push/fetch operations.
> Before working on an implementation, I'd appreciate feedback on a few
> design points:
> 1- What remote ref namespace would be appropriate?

Again, this is going to depend on the user and environment.

> 2- Should shared stashes use an explicit user-provided name or an
> object-derived identifier?

Names are going to be nicer.  We don't require people to memorize object
IDs and allow them to use branch and tag names.

> 3- Should listing only inspect remote refs, or fetch the export
> commits so stash messages can also be displayed?

Stashes can be large because they (a) can contain untracked files and
(b) contain a reference to history, so inspecting only remote refs is
going to be a lot lighter.

> 4- What command naming would fit best with the existing git stash interface?

Probably `git stash push` or something like that.

I think some nicer tooling would be helpful, so I'm in favour of that,
but I'm not sure that standardization is going to be possible.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 325 bytes --]

  reply	other threads:[~2026-09-29 22:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-28 14:27 [RFC] git stash: add porcelain for sharing stashes through remotes Hanan Arshad
2026-09-29 22:19 ` brian m. carlson [this message]
2026-10-05  5:53   ` Hanan Arshad
2026-10-05  7:47     ` Johannes Sixt
2026-10-05  8:03       ` Hanan Arshad
2026-10-05  8:21         ` Johannes Sixt
2026-10-05  9:06           ` Hanan Arshad
2026-10-05 15:25             ` Junio C Hamano
2026-10-07  6:31               ` Hanan Arshad
2026-10-07 10:36                 ` Johannes Sixt
  -- strict thread matches above, loose matches on Subject: below --
2026-10-01  8:53 Hanan Arshad
2026-10-01 22:02 ` D. Ben Knoble
2026-10-01 22:16   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=arw5XxJPNlUxU8TS@fruit.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=hananarshad619@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.