Live data from Hacker News

Git: how to use stash

softwarecave.org

31–40 of 43 posts

Re: Git: how to use stash

#31
"Normally, I would have to save the changes (diff) into some file, switch to the main branch abandoning any changes, apply the fix or improvement and commit it. Then I could switch back to my own branch, apply the changes (patch) from the file and continue the work."

Really? Why would you "normally" jump through all these hoops just to work in the same directory? Using svn, my response to this is to jump back to the root of all my projects (~/codebase/ at my current work), checkout a clean version of the branch I need to work on, make changes / test / commit, and rm -rf the whole branch, changing directory back to where I was. If I get blocked on that change for a few hours, I don't have to jump through additional hoops to go back to working on the thing that was interrupted, since I can just change directory back to it.

Is there a reason why this is an awful workflow in git?

Re: Git: how to use stash

#32
post #27

Far better: git commit -a -m 'Work in progress' Switch to other branch, do work on it. When you come back to the branch, git reset --soft HEAD^ It's far less volatile than stash, and far better at keeping WIP in the right place when things get so hectic that you have abandoned work on more than one branch. Stash is only really safe to use for very short-lived uses, such as "stash/pull/unstash"

I think it's because some workplaces have policies about not committing partially done code. ie. Don't break the build. Personally, if I'm on a local branch I don't care, but I guess it might bother some people.

In git commits are done off-line, so nobody will see the commit if you don't push it.

You can clean up such work-in-progress commits before pushing by using interactive rebase.

Re: Git: how to use stash

#33

Does anyone know why stash names are so ugly? I've always found typing "git stash apply stash@{3}" to be pretty painful (not to mention redundant).

It's a generic git syntax for "this reference 3 versions ago", see `man git-rev-parse`

It works for other things too, e.g. you can undo rebase with `git reset master@{1}` (i.e. reset master to previous location of master).

Re: Git: how to use stash

#34

"Normally, I would have to save the changes (diff) into some file, switch to the main branch abandoning any changes, apply the fix or improvement and commit it. Then I could switch back to my own branch, apply the changes (patch) from the file and continue the work." Really? Why would you "normally" jump through all these hoops just to work in the same directory? Using svn, my response to this is to jump back to the…

He's not actually talking about saving the diff and patching within a git repo, as far as I can gather from:

> [...], apply the changes (patch) from the file and continue the work. While it is not something difficult, it can be done much easier with Git.

Since he's saying "it can be done much easier with Git", the implication is that he wasn't using Git earlier, and the workflow with `git stash` is far cleaner than that diff/patch workflow.

At least, I think that's the case. I really can't imagine someone doing that instead of just using Git and `git stash` in the first place.

Re: Git: how to use stash

#35

"Normally, I would have to save the changes (diff) into some file, switch to the main branch abandoning any changes, apply the fix or improvement and commit it. Then I could switch back to my own branch, apply the changes (patch) from the file and continue the work." Really? Why would you "normally" jump through all these hoops just to work in the same directory? Using svn, my response to this is to jump back to the…

That works just fine. But if you're working on a big project, a full new download can take a while.

Re: Git: how to use stash

#36

Far better: git commit -a -m 'Work in progress' Switch to other branch, do work on it. When you come back to the branch, git reset --soft HEAD^ It's far less volatile than stash, and far better at keeping WIP in the right place when things get so hectic that you have abandoned work on more than one branch. Stash is only really safe to use for very short-lived uses, such as "stash/pull/unstash"

How is this really any better/different than just giving a message to a stash?

Re: Git: how to use stash

#37
post #5

Missing my favorite flag for stash: --include-untracked. This will also stash any files that are not currently being tracked by git.

git stash -u is much shorter :p This is default for me, now, since I've had untracked files straight up deleted because I didn't include them in my stash.

Re: Git: how to use stash

#38

Far better: git commit -a -m 'Work in progress' Switch to other branch, do work on it. When you come back to the branch, git reset --soft HEAD^ It's far less volatile than stash, and far better at keeping WIP in the right place when things get so hectic that you have abandoned work on more than one branch. Stash is only really safe to use for very short-lived uses, such as "stash/pull/unstash"

Why would you recommend reset --soft ?

To get back to where you started (changes not added to the index, since you are doing commit -a) you should do `git reset --mixed HEAD~` (or drop the --mixed argument as it's the default).

Re: Git: how to use stash

#39
post #37
post #5

Missing my favorite flag for stash: --include-untracked. This will also stash any files that are not currently being tracked by git.

git stash -u is much shorter :p This is default for me, now, since I've had untracked files straight up deleted because I didn't include them in my stash.

> I've had untracked files straight up deleted because I didn't include them in my stash.

Do you recall the actual circumstances? That shouldn't happen in the normal course of things...

Re: Git: how to use stash

#40
post #36

Far better: git commit -a -m 'Work in progress' Switch to other branch, do work on it. When you come back to the branch, git reset --soft HEAD^ It's far less volatile than stash, and far better at keeping WIP in the right place when things get so hectic that you have abandoned work on more than one branch. Stash is only really safe to use for very short-lived uses, such as "stash/pull/unstash"

How is this really any better/different than just giving a message to a stash?

how many times have you stashed, and in what stages of development, and when you try to apply them later, will they be in order and will they work on the codebase as it has changed? also, do you even remember you stashed, and is there a log longer than 1 line?

stash is a quick hack, and is useful as a quick hack, but commits just work better.

Post reply on HN