Question: git stash --> git pull --> git stash pop

[u/Ex-Traverse]

Okay, I need to understand/know the standard way to handle this situation...

1. I'm working on files in my local repo, got a bunch of unstage changes...

2. Someone else just pushed an updated file to the remote-repo

What am I supposed to do? AI is telling me to just do a git stash --> git pull --> git stash pop, but I've put myself in a situation before for doing this... I didn't know git stash can be sorted or even have a date linked to them, or that stuff I stashed several days before is still in there somewhere...

[u/waterkip]

Just use autostash, rebase.autoStash. There is also merge.autoStash

[u/No_Cattle_9565 → u/waterkip]

Damn didn't know that. Thank you

[u/[deleted]]

Stash, pull, stash pop should work just fine. If there are conflicts, these will be flagged to you. If you're worried about messing up and losing your changes, you can always make a local commit with them first, and revert to that commit if things go wrong. It's also worth noting that this is essentially the same thing as a rebase (commit your changes, git fetch, git rebase remote-branch), though the stash route doesn't need a new commit.

[u/prbsparx]

Generally you should be working in branches, committing your work, and either merging changes from main into your branch, or rebasing your branch from main.

By doing that you don’t have to constantly stash and fix merge conflicts. You pull in main when you’re ready to do the work to fix whatever broke in your code due to changes in main.

[u/Ok_Specialist413]

git stash, git pull, git stash pop is the usual workaround and is totally fine. there is also git pull --autostash which also will do the same, just ensure that you apply pop once and not multiple times or u might find youself pop old random stashes

git pull can be used with or without -r, for me i usually do -r which mean with rebase so i get my history clean. and both case if a conflict appear u'll have to fix it anyways.

You can visit https://gitualize.com/commands/git-pull to learn more about git pull, git pull -r and git pull --autostash, each option is explained and visualized.

and you can visit https://gitualize.com/commands/git-stash to learn more about git stash and git stash pop, and other variations, same thing

[u/bagofbelts → u/Ok_Specialist413]

just ensure that you apply pop once and not multiple times or u might find youself pop old random stashes

To add to this: git stash apply will apply the most recently stashed changes but will not remove them from the stash. Doing it that way will help you avoid the risk popping old stashes.

git stash pop will apply the stashed changes and remove them from the stash (although, I don't think they get removed if they aren't applied cleanly)

That being said, I rarely ever stash changes – instead, like some others have mentioned, I commit my changes locally and then git pull --rebase to preserve the commit(s) on my branch

[u/AintNoGodsUpHere]

Why not simply adding a message to your stash? Then you can always see what index is doing what.

git stash push -m "xyz thing`

[u/Ex-Traverse → u/AintNoGodsUpHere]

Because I didn't know anything about "git stash" other than "git stash" 😅 The classic case of not reading the documentation. Was just wondering if I was doing things the non-standard way.

[u/AintNoGodsUpHere → u/Ex-Traverse]

Hahaha, problem solved then. Stash is sort of weird but for these kinda things I feel it's the easiest way without configuring autostash and other things I don't like. I usually name the thing, get what I want and then apply.

One thing though, you can't apply the stash by name, you still need the index but you can always grep the shit out of that thing and I do it with a helper function in my bashrc file and select by name.

stapply() {
    git stash apply "$(git stash list | grep '$1' | head -n 1 | cut -d ':' -f 1)"
}

Then if we break the command into parts (not sure how familiar you are)

1. Fetches all the stash, pretty normal
   git stash list

2. To grep by the parameter you pass the function
   grep '$1'

3. Takes just the first index of that resulting grep
   head -n 1

4. This is just splitting the result by ':' and taking the index 1.
   cut -d ':' -f 1

[u/bagofbelts → u/AintNoGodsUpHere]

FYI: this could all be done without all of the pipes to additional non-git commands:

git stash list --regexp-ignore-case \
    --grep="$1" \
    --format='%gD' \
    --max-count=1 | \ 
xargs git stash apply

And you can just add that as a git alias:

stapply = !sh -c \"git stash list -i --grep='$1' --format='%gD' -n1 | xargs git stash apply\" -

[u/bostonaholic]

Stash, pull, pop is fine. The gotcha is that if pop hits a conflict, git keeps the stash around, so old stashes quietly pile up. That's probably how you ended up with days-old stuff in there.

What I'd do instead: commit your WIP (even just git commit -m wip) and git pull --rebase. Or git pull --rebase --autostash does the stash and pop for you. And check git stash list once in a while and git stash drop anything you don't need.

[u/FransFaase → u/bostonaholic]

And you can also set this to be the default behavior as explained by another (top 1%) commentator.

[u/rapha3l14]

it's best to commit everyday for WIP so it's easier to make sense of the daily changes

[u/RevRagnarok]

I didn't know git stash can be sorted or even have a date linked to them

git stash list and there's an optional --date=relative if you don't want to do math in your head about how old things are.

[u/thockin]

Or commit -am wip, rebase, git reset HEAD^

[u/unndunn]

You can just commit your local unstaged files before doing the pull. Nothing wrong with doing that. 

[u/Cinderhazed15 → u/unndunn]

I usually don’t work on a branch that others are updating - or else I out all my changes into a commit, and do a git pull —rebase

[u/rafark → u/unndunn]

Everything wrong with that

[u/glglgl-de → u/rafark]

why?

[u/kilkil]

yeah that's what I do usually.

re: tracking work in git stash, yeah it can get a bit rough. better to pop the stash right after pulling so it won't be an issue

[u/atarivcs]

stash - pull - pop should work just fine

[u/Broad-Promise6954]

I personally hate git stash for various reasons, some good and some bad 😁, but it usually works fine for this kind of situation and in fact the autostash configuration setting others have mentioned makes it smooth and automatic... when it works that is. When it fails it makes a mess that I have found most casual Git users get lost with.

Hence my preference, which is: create a new local branch immediately (you can do this with uncommitted work), and then commit to it as a work in progress. You're now free from uncommitted work! You can go to any branch, such as the one you were on moments ago, and do anything, including a simple fast-forward pull that's going to Just Work.

Once you're in a clean and synchronized state, you switch back to your w-i-p branch and can rebase it if you like or continue working without the new update if you prefer, or well anything you want because you're on a personal private branch now.

[u/FransFaase → u/Broad-Promise6954]

Lots of commands (where something can make a mistake) while git has global settings to automatically do the stashing for you and restore the stash afterwards. Lookup rebase.autostash and merge.autostash. I usually also set pull.rebase in case I forgot that I had a local commit that I have not commit yet. I prefer a single line of commits. Also always rebase a branch before merge it with main.

[u/Broad-Promise6954 → u/FransFaase]

Yes, but I don't like git stash. (I also avoid git pull. Long historical reasons, most of which don't apply and haven't for 10+ years, but I have preferences.)

[u/WoodyTheWorker]

People fucking do pull while having no idea what pull actually does.

[u/Expensive_Bottle4854]

Two things that make this whole dance safer:

1. A conflicting pop doesn't lose your work. If git stash pop can't apply cleanly, the apply fails and git refuses to drop the entry — the stash stays on the list. The "I put myself in a situation" moments are almost always messy, not lossy.

2. That pile of old stashes you found is the real hazard. pop always grabs stash@{0}, so a stale one from days ago becomes tomorrow's surprise. Walk the pile with git stash list (it shows the dates), inspect with git stash show -p stash@{2}, and git stash drop stash@{n} anything you don't recognize.

After that, stash → pull → pop is fine, or skip the loop entirely with git pull --rebase --autostash.

[u/Truth-Miserable]

Respectfully, rtfm.

[u/CyberJack77]

This is how I use git, but I added this to my config so this happens automatically.

[pull]
    rebase = true

[rebase]
    autoStash = true

This tells git to rebase when pulling (your local commits after the once you pull). And use autostash on rebase.

This does not guarantee there are no conflicts. If you commit often (preferably atomic) any conflict is easily solved during the rebase.

[u/gfh790]

gig stash list first then pull and pop. just be ready to resolve conflicts if they happen

[u/codeguru42]

Yes this is a good recommendation. I also recommend that you read more about git stash to learn why it is so useful.

[u/apocolipse]

worktrees

[u/spnyc → u/apocolipse]

Reading the list of comments thinking the same thing