git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Philip Oakley <philipoakley@iee.email>
To: git@vger.kernel.org
Subject: Re: Concept question about push/pull stashes
Date: Wed, 1 Sep 2021 10:23:35 +0100	[thread overview]
Message-ID: <204f8fdb-2e98-f1d2-b01b-d1e0fb0cf8b2@iee.email> (raw)
In-Reply-To: <8d2f05e6f4ff9855460402e8cdafd7e7@posteo.de>

This is a bit of 30,000ft thinko.

On 01/09/2021 08:44, c.buhtz@posteo.jp wrote:
> Hello,
> my question has to goals. I want to understand the design decisions
> behind a (missing) feature and and wan't to explore the needs of other
> users before I start to implement something.
>
> There is no usual way to exchange stashes with other repos/users.
> Stashes are code snippets that are unfinished and not clean enough to
> commit them anywhere not even in another branch.

I suspect that this "not even in another branch" is where the confusion
may arise. I've always understood git branches to be lightweight and
ephemeral. We usually fail to take that mental model to its rightful
conclusion.

While some branches are rock solid release branches, that does not
preclude their use for whimsical, unfinished snippets of code. There can
be reticence to create local wip branches (a trap I often fall into)
when we should be far more free with our branches - they take up no space!

Ultimately stashes are branches, their _extra_ capability is that they
can handle un-staged changes and other _local_ changes to allow for
interruptions.

>
> Why? What is the concept behind this? I am sure this was well thought.
> I just try to understand.
>
> A feature like this is often asked by users when you asked the search
> engine of your trust.
>
> One workaround is to simply commit the stashed code, push/pull it,
> checkoutit into the other repo and delete the last commit.

If the commit was on a new [wip] branch then a later branch deletion and
`gc` will clear it.

Isn't this an XYproblem for how to exchange snippets? And how to
decide/indicate what should be in the snippet?

>
> The other workaround is to create a patch-file from a stash. But then
> the question is how to exchange this file?

`send-email` ?
>
> Why not use the git infrastructure itself?
>
> I have workaround in my mind. I couuld use a script wich creates patch
> files for each existing stash and commit them into the repo. Thats
> all. To keep the repo "clean" the path files could be archived into a
> hidden (dotted filed) tar file. Or the tar file could be stored inside
> the ".git" folder if there is a way.

The stash does manage to combine the selection of the code change files
and creation of a branch [aka stash]. Maybe `commit` needs a --wip
option that will create the branch while adding the selected files.  The
'transmission' method would also need resolving as there are too many
ways folk interact these days - we already have patches, tar files,
remote push/fetch, then there will be web browsing methods..

>
> I am interested in your thoughts about this.

There is always (after checking the manual) `git stash branch
<branchname> [<stash>]`  - not used it myself, so it may not do what I
think I read.. Sounds like it needs combining with an initial `stash
push` to allow the new branch (containing the stash snippet) to be
exchanged using the regular methods for on-branch code.

-- 
Philip

      reply	other threads:[~2021-09-01  9:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-01  7:44 Concept question about push/pull stashes c.buhtz
2021-09-01  9:23 ` Philip Oakley [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=204f8fdb-2e98-f1d2-b01b-d1e0fb0cf8b2@iee.email \
    --to=philipoakley@iee.email \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).