4 ms·

The whole advantage of stash, the way I see it, is that you don't need to type out a whole bunch of commands to stick something into another branch and deal wit

The whole advantage of stash, the way I see it, is that you don't need to type out a whole bunch of commands to stick something into another branch and deal with remembering where you put it and what you called it and so on. I started out using secondary branches since that was the intuitive way of doing things, and I had issues with stash before, but after a while I went back to using stash again because it's just so much faster to stash my config differences, do all the necessary merges or pulls or switches, and then just stash pop. A large part of the advantage is that stash is a bit orthogonal to the usual workflow, so it goes in a specially defined place in my brain vs being yet another branch, especially if I already have work/dev/backup branches for other purposes. I agree that I wouldn't recommend using the stash to beginners, though, it does really odd things at times if you are not clean with it. First time I used stash, I lost all my code and nobody could figure out how to get it back. :P But that the thing - I never stash crucial code, just things like settings that are special to me and not other developers, so they'll probably never be pushed.

dahart 10y ago
Stash for you is fine, you obviously know what you're doing, and you use it carefully. And if you're comfortable with fsck, you really don't have to worry. OTOH, the alternative workflows are really not that hard, it's really not a ton of commands compared to using stash. The single most common use case I've heard so far is switching branches, and for that you can skip stash the majority of the time, many people don't seem to know that. Your example was stash during a pull, if you do that, your workflow is: $ git stash $ git pull $ git stash pop The alternative is: $ git commit -am "WIP" $ git pull $ git reset --soft Not only is it the same number of commands, and safer, it's also less to remember because you don't have to use the stash subsystem at all. Commit, pull, and reset are commands you have to know regardless, you can't avoid them. Stash isn't one you have to know to use git. Stash is adding to the things you have to remember, or taking up space in your head that could be used to learn flexible ways of making temporary commits & branches.
- projektir 10y ago
  I don't know if I really know what I'm doing... feel free to correct me if something feels off. I'm not following your alternative. Did you mean "git pull --rebase"? Because this will result in there being a WIP commit in the middle. I try to pretty much never do pulls like this, I'm in the "rebase everything to smithereens camp". I don't want accidental merges. I do not want to have to rebase because I got a commit in the middle and it's named funny. And what I also don't want is having to deal with merge conflicts in the rebase or merge in case incoming changes don't like the changes in the WIP commit. It's a lot cleaner to just not have the stuff in there at all, pull, and put it back on top. (like the stack that stash presents) Yes, I am that lazy. This is not really the way I used to do it. An example is just an example, the situations are many. Maybe I want to pull. Maybe I need to rebase my stuff. Maybe I need to switch to another branch to show something to a coworker. I'd have to make a special branch, commit to it, and then grab the commit hash and cherry-pick that whenever I needed it. Because I would need it in all sorts of different situations. So part of the issue was keeping track of the hash. But the bigger problem was how much work I'd needed to do if I ever needed to bring those changes up to speed again. With stash, I get a merge conflict and I resolve it, and that's my new stash again, I don't even have to do anything. With a commit or cherry-pick, I have to undo it, fix it, commit it, and now manage a new hash. I find stash easier to manage in my head specifically because it's a separate thing on the side so it doesn't get mixed up with all my other branching. It's very little headspace at this point, and mostly a decision tree in the form of: - is the staging area empty and I want to start doing work? stash pop; - is the staging area currently holding my stash changes and I want to do some things with git? stash.
  - dahart 10y ago
    > Did you mean "git pull --rebase"? Yes. > Because this will result in there being a WIP commit in the middle No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit. Doing a commit+pull+reset will always work exactly as easily as stashing. It's no less clean to commit & later reset than it is to stash & later pop. The difference is that if you commit you have a bigger safety net than if you stash. I totally understand that stash feels easier, a lot of people agree with you. But I don't think it's true once you dig down and learn how to not use stash. And stash is more dangerous when something unexpected happens.

dahart 10y ago

Stash for you is fine, you obviously know what you're doing, and you use it carefully. And if you're comfortable with fsck, you really don't have to worry. OTOH, the alternative workflows are really not that hard, it's really not a ton of commands compared to using stash. The single most common use case I've heard so far is switching branches, and for that you can skip stash the majority of the time, many people don't seem to know that. Your example was stash during a pull, if you do that, your workflow is: $ git stash $ git pull $ git stash pop The alternative is: $ git commit -am "WIP" $ git pull $ git reset --soft Not only is it the same number of commands, and safer, it's also less to remember because you don't have to use the stash subsystem at all. Commit, pull, and reset are commands you have to know regardless, you can't avoid them. Stash isn't one you have to know to use git. Stash is adding to the things you have to remember, or taking up space in your head that could be used to learn flexible ways of making temporary commits & branches.

projektir 10y ago
I don't know if I really know what I'm doing... feel free to correct me if something feels off. I'm not following your alternative. Did you mean "git pull --rebase"? Because this will result in there being a WIP commit in the middle. I try to pretty much never do pulls like this, I'm in the "rebase everything to smithereens camp". I don't want accidental merges. I do not want to have to rebase because I got a commit in the middle and it's named funny. And what I also don't want is having to deal with merge conflicts in the rebase or merge in case incoming changes don't like the changes in the WIP commit. It's a lot cleaner to just not have the stuff in there at all, pull, and put it back on top. (like the stack that stash presents) Yes, I am that lazy. This is not really the way I used to do it. An example is just an example, the situations are many. Maybe I want to pull. Maybe I need to rebase my stuff. Maybe I need to switch to another branch to show something to a coworker. I'd have to make a special branch, commit to it, and then grab the commit hash and cherry-pick that whenever I needed it. Because I would need it in all sorts of different situations. So part of the issue was keeping track of the hash. But the bigger problem was how much work I'd needed to do if I ever needed to bring those changes up to speed again. With stash, I get a merge conflict and I resolve it, and that's my new stash again, I don't even have to do anything. With a commit or cherry-pick, I have to undo it, fix it, commit it, and now manage a new hash. I find stash easier to manage in my head specifically because it's a separate thing on the side so it doesn't get mixed up with all my other branching. It's very little headspace at this point, and mostly a decision tree in the form of: - is the staging area empty and I want to start doing work? stash pop; - is the staging area currently holding my stash changes and I want to do some things with git? stash.
- dahart 10y ago
  > Did you mean "git pull --rebase"? Yes. > Because this will result in there being a WIP commit in the middle No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit. Doing a commit+pull+reset will always work exactly as easily as stashing. It's no less clean to commit & later reset than it is to stash & later pop. The difference is that if you commit you have a bigger safety net than if you stash. I totally understand that stash feels easier, a lot of people agree with you. But I don't think it's true once you dig down and learn how to not use stash. And stash is more dangerous when something unexpected happens.