Git stashing, and why you do it too much

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:

  1. It preserves some history about the idea (what else I was doing at the same time)
  2. It makes tracking what you’re doing a lot simpler (because the stash stack is a pain at the best of times)
  3. 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.

About richo

I enjoy exploring interesting concepts in weird languages. I also like hacking on all of the things.
This entry was posted in Articles and tagged , , , . Bookmark the permalink.

2 Responses to Git stashing, and why you do it too much

  1. knittl says:

    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)

    This is not entirely correct. Try gitk --all to see how a stash is represented in the Git history DAG.
    Granted, if you simply call git stash pop, Git tries to apply the stashed changes on top of the current commit, which may not be what you wanted.

    Nevertheless, git stash even provides a neat way to make stashes permanent:

    If the apply tries to modify a file that you’ve since modified, you’ll get a merge conflict and will have to try to resolve it. If you want an easier way to test the stashed changes again, you can run git stash branch, which creates a new branch for you, checks out the commit you were on when you stashed your work, reapplies your work there, and then drops the stash if it applies successfully:

  2. richo says:

    Thanks, I wasn’t aware of that. I should do some more reading then update this post.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>