tags:

views:

4739

answers:

3

In a previous Git question, Daniel Benamy was talking about a workflow in Git:

I was working on master and committed some stuff and then decided I wanted to put that work on hold. I backed up a few commits and then branched from before I started my crap work.

He wanted to restore his working state to a previous point in time without losing his current changes. All of the answers revolved around, in various ways, something like

git branch -m master crap_work
git branch -m previous_master master

How does this compare to git stash? I'm a bit confused trying to see what the different use case here when it seems like everything git stash does is already handled by branching…


@Jordi Bunster: Thanks, that clears things up. I guess I'd kind of consider "stashing" to be like a lightweight, nameless, branch. So anything stash can do, branch can as well but with more words. Nice!

+20  A: 

'stash' takes the uncommitted, "dirty" stuff on your working copy, and stashes it away, leaving you with a clean working copy.

It doesn't really branch at all. You can then apply the stash on top of any other branch. Or, as of Git 1.6, you can do:

git stash branch <branchname> [<stash>]

to apply the stash on top of a new branch, all in one command.

So, stash works great if you have not committed to the "wrong" branch yet.

If you've already committed, then the workflow you describe in your question is a better alternative. And by the way, you're right: Git is very flexible, and with that flexibility comes overlapping functionality.

Jordi Bunster
one thing that bites me... can you write what a [<stash>] actually looks like! They put it in that notation in the docs, but it's not obvious whether that should be 1 or @{1} or what.
Gregg Lind
If you want to refer to a specific stash "N", use stash@{N}
Jordi Bunster
See `git stash list` for the names of your stashes.
pydave
+4  A: 

I'm always wary of git stash. If you stash a few times, things tend to get messy. git stash list will display a numbered list of stashes you created, with messages if you provided them... But the problem lies in the fact that you can't clean up stashes except with a brutal git stash clear (which removes them all). So unless you're always anal in giving super-descriptive messages for your stashes (kinda goes against stash's philosophy), you end up with an incomprehensible bunch of stashes.

The only way I know of to figure out which one's which is to use gitk --all and spot the stashes. At least this lets you see what commit the stash was created on, as well as the diff of everything included in that stash.

Note that I'm using git 1.5.4.3, and I think 1.6 adds git stash pop, which I guess would apply the selected stash and remove it from the list. Which seems a lot cleaner.

For now, I always try to branch unless I'm absolutely positive I'm gonna get back to that stash in the same day, even within the hour.

webmat
Do you make branches without giving them useful names? If not, then I don't see why you don't do the same with stash. If you really want to know what they contain, you just use git-stash show to show which files changed, or git-stash apply and git-diff to see the actual diffs. Keeping stashes trimmed down is just the same as keeping your branches under control.
Xiong Chiamiov
+5  A: 

Read the following article for more info on using the stash: http://ariejan.net/2008/04/23/git-using-the-stash/

Ariejan