First of all, this workflow depends entirely on an (rarely un)spoken rule in my repositories- if it’s in the wip/ or trash/ tree, don’t touch it. I’m planning on rebasing with impunity.
I stash a lot at work, especially when I shouldn’t.
Generally, stashing occurs when I’m working on something that’s not ready for production or even feature complete enough to warrant publishing, and I need to rebase or start on something else. Nearly always I stash it and forget about it (even though my prompt yells at me when I have stashes)
The alternative is to check it into a wip/ or trash/ branch (depending on how confident I feel about the change in question being a Good Idea). This is useful for a stack of reasons:
- It preserves some history about the idea (what else I was doing at the same time)
- It makes tracking what you’re doing a lot simpler (because the stash stack is a pain at the best of times)
- Most importantly, you can keep branching
The last one is the most relevant, a stash isn’t rooted to any particular point on the tree which means if you make an invasive change you’re going to struggle (which is a pain when the patch in question alters some core behaviour and was only barely working to start with)
If I know it’s going to be a problem that I take a lot of stabs at I’ll generally make it a branch like wip/ideas/short_description_of_approach for simplicity to begin with; and this will only get better in git 1.7.9 which adds a description attribute for branches.
Stashes are awesome for getting a clean tree so you can rebase or do some non-trivial merging, but for keeping ideas straight it’s a pain; to the point where I’m considering a hook to delete my stashes after a week so that I can just be rid of them.
2 Responses to Git stashing, and why you do it too much