Hacker News Reader

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.

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.

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.

> 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 [1] https://docs.microsoft.com/en-us/aspnet/core/security/app-se...

Thanks, I will review that. We are working on ASP.NET stuff and using Web.configs in a non-standard way (don't get me started) to store encrypted strings for... anyway, you get the idea. This is in the queue to get overhauled soon, so hopefully won't be an issue much longer (if you squint, you can see the end of the todo list wayyy back there). Maybe I should check this out.

Same for me. I only ever use stash in cases where I don't materially care if I never see the content again, as with an experimental approach.

I don't think there's anything wrong with stashes, but there's another interesting trick that you might want to try for this purpose: commit the dead-end, then immediately make a revert commit. You can even add a rationale in the revert commit message.

The technique is not applicable all the time, but for those instances when you really think it's valuable to preserve the knowledge that was gained in trying and abandoning a particular approach it's great.

I started using emacs recently, largely for org-mode and magit. The default stash behavior of prompting for a message in magit helps me a lot with the problem of keeping stashes organized and knowing when old stashes I’ve forgotten about are safe to get rid of. Even when working on the command line now, I try to always stash with a message to provide some context for future me.

    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.

Alternatively, instead of `git reset HEAD^` you could do `git commit --amend` to merge further changes into the latest commit

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.

This. I have these aliased as `git save` and `git unsave`, which makes it as convenient as `git stash`.

If anyone is interested, there's a tiny utility I've used daily for years to do this: 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.

I do this all the time, it’s the only real way of saving state when you are abruptly asked to do something else

> 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.

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.

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.

Yea, exactly. The author's git workflow is eerily like the one I've converged too over a decade, but "never stash" (without acknowledging the existence of the quick stash use-case) is wrong enough that it's enough to give me pause about his general competency with git (or more likely and more charitably, that he just didn't put too much effort into that section of the article).

The advantage of stash is that it's quicker and easier than creating and cleaning up branches. If you're naming stashes and keeping them longterm, then you're basically using them like branches and should consider what benefit you're getting from adding a separate workflow.

A lot of my "short term" things end up being multi-month distractions or worse - and the verify/list/drop cycle is reflexive paranoia after one too many botched merges lost data.

Sometimes those botched mergeds have been due to my own incompetence, sometimes due to P4Merge literally corrupting my file and saving out something totally different than what I'd resolved, and sometimes due to unexpected refactoring between branches causing enough of a mess that reapplying the work by hand is easier than "resolving" the conflict.

Good points all round.

But what I'm not doing is saying "you should always use stash". I'm providing use cases, for me personally, where stash is the correct approach.

"Ah", but you might be inclined to argue, "such and such a reason". Yes, but also no.

Right tool for the right job is also an argument for competency and context. Sometimes a hammer is useful for more than just hammering, but very rarely.

The point is there is usually more than just 1 approach, and niche/edge cases can be real nasty if approached with the attitude that everything is a nail

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.

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.

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.

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

Perhaps a Mercurial user can say if shelves are more useful? (And if so, why?).

I'm a Mercurial user and I use bookmarks instead, aka git-like branches.

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.

TIL, thanks! I've been stash; rebase; pop'ing

> 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.

>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.

And another episode of "how did I not know git did this". Thanks for this.

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

> 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.

> 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-s...

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

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.

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

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