6 ms·

>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's no

>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream changes you missed. It can, but it does waaaay more. What happens if, like many people, you're working on a few branches at a time. Could be a monorepo, could be a couple long living branches, w/e. What do you do if you've done work against a branch and want to lift and shift to another branch? You could commit and rebase and all sorts of clever mangling of the history. OR you could use the right tool for the job --- Follow up [0] https://medium.com/@yankee.exe/mastering-git-stash-workflow-a310313ca7b6 https://medium.com/@yankee.exe/mastering-git-stash-workflow-... [1] https://git-scm.com/book/fa/v2/Git-Tools-Stashing-and-Cleaning https://git-scm.com/book/fa/v2/Git-Tools-Stashing-and-Cleani...

stinos 6y ago
>Never stash Er, no. Right tool for the right job. Yup. pull --rebase --autostash for example. Technically also stashing, and would be insane not to use it :) More serious note: agreed. I use stashing multiple times a day and never have problems with things being messy. Though I admit I usually look t stashed in a gui, not from the terminal.
- bradstewart 6y ago
  And another episode of "how did I not know git did this". Thanks for this.
kingosticks 6y ago
The author does explain their alternative to stash (a temporary commit in the new branch that will eventually be cleaned up / removed during 'rebase -i' before pushing) and why that fits with the way they work. Why is stash better than this? Because it avoids the rebase? Many people do this anyway, early commit messages often need rewording. Because it maintains the separate state of the current working directory and the index? Is that it? I don't think that's really a compelling enough reason to claim the author's avoidance of stash is the wrong way to work.
yarcob 6y ago
The problem with stash is that its easy to create a mess. Yes, it's useful to quickly stash your work, switch to a different branch, do some quick fix, then go back to your original branch. But in practice, what often happens is that your quick fix takes way longer than expected, and you don't immediately go back to your original branch. Then you pull in some changes, maybe someone else pushed something to the branch you were working on, and you end up with a bunch of stashes on outdated branches and it's really hard to make sense of it all. Most of my working copies have at least half a dozen old stashes that I don't remember any details about anymore. One approach to avoid this mess that git stash can lead to is to never use it, and just commit all your work before switching to a different branch. Clean up the current state of the repo, try to document your changes in the commit message, and commit them. Then switch branches. You can always squash or rewrite the commits later, and it's a lot easier rebasing or merging a few old commits than working with stashes. If you like stashes, please use them! But I agree with the author, using them a lot can lead to a mess, and temporary branches are usually a cleaner way of saving your work.
- gtsteve 6y ago
  I personally only use stashes when I've given up on my current approach and want to reset but I might change my mind later (rarely happens). I don't think they're appropriate for stuff you want to keep across branches, there's no real visibility and they'd be easily forgotten.
  - zikzak 6y ago
    I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc. I realize this isn't a best practice for config files but it is what I need to do for my particular mountain of technical debt. This works particularly well since the config files rarely change in a permanent way. I will only do it short term, though. For me, Stash is a tool I use sparingly as a convenience.
    - laudable-logic 6y ago
      > I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc. I had to resort to git's assume-unchanged[O] to keep these changes out of commits made in the heat of battle. > this isn't a best practice for config files Have had great results (in dotnet land) with MS' Secrets Manager[1]. [0] https://www.git-scm.com/docs/git-update-index https://www.git-scm.com/docs/git-update-index [1] https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-3.1&tabs=windows#secret-manager https://docs.microsoft.com/en-us/aspnet/core/security/app-se...
brmgb 6y ago
I don't understand your comment about tools. Checkout is a git command (with an admittedly terrible ux). It is not part of git data model. Like the article writer, I never myself use stash. I personally don't understand why they were added to the git ux. I think they needlessly make git more complex. Under the hood, a stash is just a commit anyway. You might retort that this is an implementation detail but as usual with Git, this leaks into the way it is used: if you ever lose a stash by mistake, you will have to go fish the corresponding commit in the reflog.
- zwp 6y ago
  I have a vague recollection of feature parity with Mercurial's shelves but I don't remember which came first. They look very similar: https://www.mercurial-scm.org/wiki/ShelveExtension https://www.mercurial-scm.org/wiki/ShelveExtension Perhaps a Mercurial user can say if shelves are more useful? (And if so, why?).
  - steerablesafe 6y ago
    I'm a Mercurial user and I use bookmarks instead, aka git-like branches.
- hibbelig 6y ago
  I use stashes via the autostash feature. For unspeakable reasons, I have to have locally modified files in my repo to run the software and the tests. (Of course, it shouldn't be like this.) So I can `git pull --rebase --autostash` and this works even with local modifications.
  - karmakaze 6y ago
    TIL, thanks! I've been stash; rebase; pop'ing
Vinnl 6y ago
> What happens if, like many people, you're working on a few branches at a time. Could be a monorepo, could be a couple long living branches, w/e. What do you do if you've done work against a branch and want to lift and shift to another branch? One "right tool for the job" I really underappreciated until recently is git worktree, which fits this use case neatly, I think, without the risk of losing your stash.
ricardobeat 6y ago
git add . git commit -m "wip" when you're back git reset HEAD^ Keeps working changes nice and tidy in the branch they belong to, you can push them, and they are easily recoverable from the ref log, unlike stashes. Also, god help you when a stash fails to apply.
- FreeFull 6y ago
  Alternatively, instead of `git reset HEAD^` you could do `git commit --amend` to merge further changes into the latest commit
- IggleSniggle 6y ago
  I needed this comment today. I am an avid stasher, despite knowing the downsides. It’s just so convenient (until it’s not...at which point I usually give up and trash it, and yell at myself for not settling into a partial commit sooner). But this workflow (which seems so very obvious in retrospect), keeps my current workflow, with so many benefits. The only place where it even requires extra steps is when you want to apply the stash to a different branch, and even there, it just feels right: “Oh yeah, I was working on that feature over there, let’s pop it off and go put it on this feature over here.” Since this generally requires careful diffing anyway to make sure things end up in the right place, there’s not much lost here, and without the downsides of stash.
- bradstewart 6y ago
  This. I have these aliased as `git save` and `git unsave`, which makes it as convenient as `git stash`.
- bitjson 6y ago
  If anyone is interested, there's a tiny utility I've used daily for years to do this: https://github.com/bitjson/wip https://github.com/bitjson/wip Each time you run `wip`, all current work is committed. When you run the squashing utility `naenae` (autocomplete: `nae + Tab`), the most recent line of "WIP" commits is saved to a `wip-archives/[branch]/[timestamp]` branch for safe keeping, the commits are all squashed in place, and you're left in your default git editor to define the commit message. It also handles unusual situations, like using `wip` for the first commit (in which case, `git reset HEAD^` will return an error). Being able to set a sort of "WIP checkpoint" in the current working directory makes it really easy to start or back out of big changes, and it can be very useful to check back in past WIP commits to grab segments of code you previously threw away.
MaulingMonkey 6y ago
> You could commit and rebase and all sorts of clever mangling of the history. > OR you could use the right tool for the job Stashes are just another form of DAG node with their own special syntax and commands and quirks. I've already learned one set of commands for all that, why learn a second, less general set of commands? I have started using stashes in one very specific case: 1. I realize I'm on the wrong branch 2. I've made no commits 3. The right branch has changes to files I've modified git stash push git checkout -b newbranch upstream/right git stash apply ...verify... git stash list git stash drop [id] Careful and safe, but not actually much faster than my old workflow, and I haven't the foggiest idea how to fix things up with stash if I've made several commits, if that's even a thing. git checkout -b dead/wrong git add -A . git commit -m "WIP" git checkout -b newbranch git rebase --onto upstream/right upstream/wrong ...verify... # optional # git branch -D dead/wrong # git reset --soft HEAD~1 Depending on if you count the optional commands, that's one more or one less command. "Those aren't optional!" you might say - but yes, they are. I'll often merely amend my WIP commit into a real one instead of resetting. I'll often keep dead branches long term - perhaps some of my work relied on things that haven't landed on upstream/right yet, and can't be brought over sanely until upstream/wrong lands on upstream/right, or just for peace of mind that I might've forgotten something. Good dead branch names makes this less painful than... numbered stashes? Eww, gross.
- IggleSniggle 6y ago
  I usually do comment my stashes for this reason (git stash save “words to remind me what this is”). But I’ve also been convinced by comments here that I’m going to be happier with WIP commits. I like making all my commits “canonical at all times,” but that’s just something I can see it’s time for me to evolve beyond.
- theamk 6y ago
  stash is supposed to be a short term thing, if you are doing the whole "apply/verify/list/drop" cycle, named branches are a superior approach. I find the power of the stash in "stash pop", which applies, and drops if there were no conflicts: git stash push git checkout -b newbranch upstream/right git stash pop and yeah, if your keep your branches long-term stash is not a good solution for this.
norswap 6y ago
My personal rule is "never go to sleep with a stash on the stack". They are for short terms manipulations, but it's easy to make mistakes with them and lose data (dropped stashes don't show up in the reflog for instance). Things to be preserved for longer should be committed and saved in temporary branches.
lucideer 6y ago
> Stash is used to record the current state of the working directory and index while also returning to a clean working state. Er, no. Stash does not return to a clean working state. Stash stashes modifications, not new files. And it makes a real mess if those new files happen to exist on another branch you want to check out. Stash seems like a half-implemented feature tbh, if only for the infuriating limitation above. It's really just not safe to use.
- Nagyman 6y ago
  > Adding the -u option (or --include-untracked) tells git stash to also stash your untracked files. https://www.atlassian.com/git/tutorials/saving-changes/git-stash https://www.atlassian.com/git/tutorials/saving-changes/git-s...
SassyGrapefruit 6y ago
Agreed! I have trouble taking anyone's advice seriously(even if they contribute to a major library) when they say the phrase "Never do X". The only thing I feel confident in saying I'll never do is committing to the prospect of never doing something. "One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision." -Bertrand Russel
kcolford 6y ago
If you're working on something and have to switch to another branch to do something else midway, that's what git-worktree is for.
smokey_circles 6y ago
Well this blew up and lots of you missed the point > right tool for the right job I'll give you that this is (slightly) ambigious. But here's the gist >you can safely ignore the opinion of anyone who says "never do X" There are lots of alternative tools listed in this comment tree. Stash has a purpose. You should know what that purpose is. A tool is only as good as its user
corytheboyd 6y ago
git is versatile enough to enable the authors workflow and your workflow, where neither are invalid. I’d be willing to bet they sometimes, even if rarely, use stash when as you say it’s the right tool to use. I think the point is not stashing meaningful amounts of changes, as if they can be recalled later. Sounds like solid advice that requires some discipline
dahart 6y ago
Adopting a policy to never stash is a good idea, because "If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms." https://git-scm.com/docs/git-stash https://git-scm.com/docs/git-stash
deleted 6y ago
[deleted]

stinos 6y ago

>Never stash Er, no. Right tool for the right job. Yup. pull --rebase --autostash for example. Technically also stashing, and would be insane not to use it :) More serious note: agreed. I use stashing multiple times a day and never have problems with things being messy. Though I admit I usually look t stashed in a gui, not from the terminal.

bradstewart 6y ago
And another episode of "how did I not know git did this". Thanks for this.

kingosticks 6y ago

The author does explain their alternative to stash (a temporary commit in the new branch that will eventually be cleaned up / removed during 'rebase -i' before pushing) and why that fits with the way they work. Why is stash better than this? Because it avoids the rebase? Many people do this anyway, early commit messages often need rewording. Because it maintains the separate state of the current working directory and the index? Is that it? I don't think that's really a compelling enough reason to claim the author's avoidance of stash is the wrong way to work.

yarcob 6y ago

The problem with stash is that its easy to create a mess. Yes, it's useful to quickly stash your work, switch to a different branch, do some quick fix, then go back to your original branch. But in practice, what often happens is that your quick fix takes way longer than expected, and you don't immediately go back to your original branch. Then you pull in some changes, maybe someone else pushed something to the branch you were working on, and you end up with a bunch of stashes on outdated branches and it's really hard to make sense of it all. Most of my working copies have at least half a dozen old stashes that I don't remember any details about anymore. One approach to avoid this mess that git stash can lead to is to never use it, and just commit all your work before switching to a different branch. Clean up the current state of the repo, try to document your changes in the commit message, and commit them. Then switch branches. You can always squash or rewrite the commits later, and it's a lot easier rebasing or merging a few old commits than working with stashes. If you like stashes, please use them! But I agree with the author, using them a lot can lead to a mess, and temporary branches are usually a cleaner way of saving your work.

gtsteve 6y ago
I personally only use stashes when I've given up on my current approach and want to reset but I might change my mind later (rarely happens). I don't think they're appropriate for stuff you want to keep across branches, there's no real visibility and they'd be easily forgotten.
- zikzak 6y ago
  I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc. I realize this isn't a best practice for config files but it is what I need to do for my particular mountain of technical debt. This works particularly well since the config files rarely change in a permanent way. I will only do it short term, though. For me, Stash is a tool I use sparingly as a convenience.
  - laudable-logic 6y ago
    > I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc. I had to resort to git's assume-unchanged[O] to keep these changes out of commits made in the heat of battle. > this isn't a best practice for config files Have had great results (in dotnet land) with MS' Secrets Manager[1]. [0] https://www.git-scm.com/docs/git-update-index https://www.git-scm.com/docs/git-update-index [1] https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-3.1&tabs=windows#secret-manager https://docs.microsoft.com/en-us/aspnet/core/security/app-se...

brmgb 6y ago

I don't understand your comment about tools. Checkout is a git command (with an admittedly terrible ux). It is not part of git data model. Like the article writer, I never myself use stash. I personally don't understand why they were added to the git ux. I think they needlessly make git more complex. Under the hood, a stash is just a commit anyway. You might retort that this is an implementation detail but as usual with Git, this leaks into the way it is used: if you ever lose a stash by mistake, you will have to go fish the corresponding commit in the reflog.

zwp 6y ago
I have a vague recollection of feature parity with Mercurial's shelves but I don't remember which came first. They look very similar: https://www.mercurial-scm.org/wiki/ShelveExtension https://www.mercurial-scm.org/wiki/ShelveExtension Perhaps a Mercurial user can say if shelves are more useful? (And if so, why?).
- steerablesafe 6y ago
  I'm a Mercurial user and I use bookmarks instead, aka git-like branches.
hibbelig 6y ago
I use stashes via the autostash feature. For unspeakable reasons, I have to have locally modified files in my repo to run the software and the tests. (Of course, it shouldn't be like this.) So I can `git pull --rebase --autostash` and this works even with local modifications.
- karmakaze 6y ago
  TIL, thanks! I've been stash; rebase; pop'ing

Vinnl 6y ago

> What happens if, like many people, you're working on a few branches at a time. Could be a monorepo, could be a couple long living branches, w/e. What do you do if you've done work against a branch and want to lift and shift to another branch? One "right tool for the job" I really underappreciated until recently is git worktree, which fits this use case neatly, I think, without the risk of losing your stash.

ricardobeat 6y ago

git add . git commit -m "wip" when you're back git reset HEAD^ Keeps working changes nice and tidy in the branch they belong to, you can push them, and they are easily recoverable from the ref log, unlike stashes. Also, god help you when a stash fails to apply.

FreeFull 6y ago
Alternatively, instead of `git reset HEAD^` you could do `git commit --amend` to merge further changes into the latest commit
IggleSniggle 6y ago
I needed this comment today. I am an avid stasher, despite knowing the downsides. It’s just so convenient (until it’s not...at which point I usually give up and trash it, and yell at myself for not settling into a partial commit sooner). But this workflow (which seems so very obvious in retrospect), keeps my current workflow, with so many benefits. The only place where it even requires extra steps is when you want to apply the stash to a different branch, and even there, it just feels right: “Oh yeah, I was working on that feature over there, let’s pop it off and go put it on this feature over here.” Since this generally requires careful diffing anyway to make sure things end up in the right place, there’s not much lost here, and without the downsides of stash.
bradstewart 6y ago
This. I have these aliased as `git save` and `git unsave`, which makes it as convenient as `git stash`.
bitjson 6y ago
If anyone is interested, there's a tiny utility I've used daily for years to do this: https://github.com/bitjson/wip https://github.com/bitjson/wip Each time you run `wip`, all current work is committed. When you run the squashing utility `naenae` (autocomplete: `nae + Tab`), the most recent line of "WIP" commits is saved to a `wip-archives/[branch]/[timestamp]` branch for safe keeping, the commits are all squashed in place, and you're left in your default git editor to define the commit message. It also handles unusual situations, like using `wip` for the first commit (in which case, `git reset HEAD^` will return an error). Being able to set a sort of "WIP checkpoint" in the current working directory makes it really easy to start or back out of big changes, and it can be very useful to check back in past WIP commits to grab segments of code you previously threw away.

MaulingMonkey 6y ago

> You could commit and rebase and all sorts of clever mangling of the history. > OR you could use the right tool for the job Stashes are just another form of DAG node with their own special syntax and commands and quirks. I've already learned one set of commands for all that, why learn a second, less general set of commands? I have started using stashes in one very specific case: 1. I realize I'm on the wrong branch 2. I've made no commits 3. The right branch has changes to files I've modified git stash push git checkout -b newbranch upstream/right git stash apply ...verify... git stash list git stash drop [id] Careful and safe, but not actually much faster than my old workflow, and I haven't the foggiest idea how to fix things up with stash if I've made several commits, if that's even a thing. git checkout -b dead/wrong git add -A . git commit -m "WIP" git checkout -b newbranch git rebase --onto upstream/right upstream/wrong ...verify... # optional # git branch -D dead/wrong # git reset --soft HEAD~1 Depending on if you count the optional commands, that's one more or one less command. "Those aren't optional!" you might say - but yes, they are. I'll often merely amend my WIP commit into a real one instead of resetting. I'll often keep dead branches long term - perhaps some of my work relied on things that haven't landed on upstream/right yet, and can't be brought over sanely until upstream/wrong lands on upstream/right, or just for peace of mind that I might've forgotten something. Good dead branch names makes this less painful than... numbered stashes? Eww, gross.

IggleSniggle 6y ago
I usually do comment my stashes for this reason (git stash save “words to remind me what this is”). But I’ve also been convinced by comments here that I’m going to be happier with WIP commits. I like making all my commits “canonical at all times,” but that’s just something I can see it’s time for me to evolve beyond.
theamk 6y ago
stash is supposed to be a short term thing, if you are doing the whole "apply/verify/list/drop" cycle, named branches are a superior approach. I find the power of the stash in "stash pop", which applies, and drops if there were no conflicts: git stash push git checkout -b newbranch upstream/right git stash pop and yeah, if your keep your branches long-term stash is not a good solution for this.

norswap 6y ago

My personal rule is "never go to sleep with a stash on the stack". They are for short terms manipulations, but it's easy to make mistakes with them and lose data (dropped stashes don't show up in the reflog for instance). Things to be preserved for longer should be committed and saved in temporary branches.

lucideer 6y ago

> Stash is used to record the current state of the working directory and index while also returning to a clean working state. Er, no. Stash does not return to a clean working state. Stash stashes modifications, not new files. And it makes a real mess if those new files happen to exist on another branch you want to check out. Stash seems like a half-implemented feature tbh, if only for the infuriating limitation above. It's really just not safe to use.

Nagyman 6y ago
> Adding the -u option (or --include-untracked) tells git stash to also stash your untracked files. https://www.atlassian.com/git/tutorials/saving-changes/git-stash https://www.atlassian.com/git/tutorials/saving-changes/git-s...

SassyGrapefruit 6y ago

Agreed! I have trouble taking anyone's advice seriously(even if they contribute to a major library) when they say the phrase "Never do X". The only thing I feel confident in saying I'll never do is committing to the prospect of never doing something. "One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision." -Bertrand Russel

kcolford 6y ago

If you're working on something and have to switch to another branch to do something else midway, that's what git-worktree is for.

smokey_circles 6y ago

Well this blew up and lots of you missed the point > right tool for the right job I'll give you that this is (slightly) ambigious. But here's the gist >you can safely ignore the opinion of anyone who says "never do X" There are lots of alternative tools listed in this comment tree. Stash has a purpose. You should know what that purpose is. A tool is only as good as its user

corytheboyd 6y ago

git is versatile enough to enable the authors workflow and your workflow, where neither are invalid. I’d be willing to bet they sometimes, even if rarely, use stash when as you say it’s the right tool to use. I think the point is not stashing meaningful amounts of changes, as if they can be recalled later. Sounds like solid advice that requires some discipline

dahart 6y ago

Adopting a policy to never stash is a good idea, because "If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms." https://git-scm.com/docs/git-stash https://git-scm.com/docs/git-stash

deleted 6y ago

[deleted]