public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Phillip Wood <phillip.wood123@gmail•com>
To: Brooke Kuhlmann <brooke@alchemists•io>, git@vger•kernel.org
Cc: "brian m . carlson" <sandals@crustytoothpaste•net>
Subject: Re: Git Stash Synchronization - Best Workflow?
Date: Mon, 1 Sep 2025 11:10:02 +0100	[thread overview]
Message-ID: <5dee5f49-eeb6-49e2-8bca-6ae6a1d6be5d@gmail.com> (raw)
In-Reply-To: <7B1CCA36-23F1-410D-84ED-6E965989EA8B@alchemists.io>

Hi Brooke

[I've cc'd brian to see what he thinks about setting up a reflog by 
default when exporting stashes]

On 01/09/2025 00:25, Brooke Kuhlmann wrote:
> Hello.
> 
> When using Git 2.51.0, what is the correct way to safely export
 > your stash and then keep that stash up-to-date? Here's an example
 > workflow:>
> touch demo.txt
> 
> git stash push --include-untracked --message "Demo"
> git stash export --to-ref "refs/stashes/$USER"
> git push origin "refs/stashes/$USER"
> 
> git stash pop stash@{0}
> git push origin "refs/stashes/$USER"

This push doesn't do anything because refs/stashes/$USER is unchanged 
since the last push

> git stash push --include-untracked --message "Demo II"
> git stash export --to-ref "refs/stashes/$USER"
> git push origin "refs/stashes/$USER"

This push fails because you've popped and then pushed a stash since the 
last export so refs/stashes/$USER on the remote cannot fast-forward
> Notice, in the middle, I pop the stash only to rename it. Upon 
 > pushing these changes back up, I get the following error:>
> To https://github.com/bkuhlmann/test
>   ! [rejected]                  refs/stashes/bkuhlmann -> refs/stashes/bkuhlmann (non-fast-forward)
> error: failed to push some refs to 'https://github.com/bkuhlmann/test'
> hint: Updates were rejected because a pushed branch tip is behind its remote
> hint: counterpart. If you want to integrate the remote changes, use 'git pull'
> hint: before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
> 
> The work around is to use `git push --force` when pushing updates.
 > I'd like to use `git push --force-with-lease` but that doesn't work.
You can use --force-with-lease=refs/stashes/$USER:$expect where $expect 
is the value of refs/stashes/$USER when you last pushed. The problem is 
that there is no easy way to find that as by default refs/stashes/$USER 
does not have a reflog and there is no remote tracking ref set up for it 
either. If you add a fetch refspec like

     refs/stashes/*:refs/remote/origin/stashes/*

(note "remote" rather than "remotes" to avoid clashing with the default 
refspec for branches) then refs/remote/origin/stashes/$USER should be 
updated when you push to or pull from refs/stashes/* and I think a bare 
--force-with-lease will work. In general --force-with-lease without 
explicitly specifying $expect is not that safe as it will happily 
overwrite the remote ref if you fetch and do not incorporate the remote 
changes into your local changes before pushing. Using 
--force-if-includes is safer if you don't want to give $expect 
explicitly. That requires a reflog for the local ref though which you 
can enable by setting core.logAllrefUpdates=always. We should perhaps 
change the export code to create a reflog for the ref we're exporting 
the stashes to and maybe expand the documentation to mention setting up 
a fetch refspec.

Thanks

Phillip

> I realize that force pushing over your remote stash makes a lot more sense since you typically never share a stash with folks but was thinking it would be nice to ensure you don't accidentally override your remote stash when working on different machine when you forgot to import first. Basically, wanting to protect myself from myself. :)
> 
> Is force push the only way to handle this use case or is there a better approach? Thanks!


  reply	other threads:[~2025-09-01 10:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-31 23:25 Git Stash Synchronization - Best Workflow? Brooke Kuhlmann
2025-09-01 10:10 ` Phillip Wood [this message]
2025-09-01 20:48   ` Brooke Kuhlmann
2025-09-05 14:03     ` Phillip Wood
2025-09-06 12:50       ` Brooke Kuhlmann
2025-09-10  9:52         ` Phillip Wood
2025-09-11  2:22           ` Brooke Kuhlmann
2025-09-19 14:04             ` Phillip Wood
     [not found]               ` <A42DC91A-91F2-4AB6-B0EE-52DE5135E99E@alchemists.io>
2025-09-19 19:54                 ` Brooke Kuhlmann

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=5dee5f49-eeb6-49e2-8bca-6ae6a1d6be5d@gmail.com \
    --to=phillip.wood123@gmail$(echo .)com \
    --cc=brooke@alchemists$(echo .)io \
    --cc=git@vger$(echo .)kernel.org \
    --cc=phillip.wood@dunelm$(echo .)org.uk \
    --cc=sandals@crustytoothpaste$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox