5 ms·

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 --re

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.
- projektir 10y ago
  > No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit. I was talking about the non-rebase version. You didn't address the rest of my post: there are other cases. This will work for that particular case, but it's not a general-purpose solution. If I have branch X with config changes, and coworker wants me to switch to branch Y but I still want my config changes, what do I do?
  - dahart 10y ago
    Stash is not a general purpose solution. You don't ever need to stash. There is nothing you can do with stashes that you can't do with core git commands, and the reverse is not true. Git could eliminate the stash command tomorrow without any loss of functionality. What if you already committed your config changes to branch X, and your coworker wants them in Y? What if you you're working along and you have commits, staged changes, unstaged changes, and you need to branch 3 commits ago instead? Stash doesn't help with either of those, and the workflow I'm advocating - just use commits and branches for temporary work - does. Stash really only helps you if you don't like to commit often, and you spend most of your time with unstaged changes in your working tree. Nothing wrong with that, if that's how you like to work, but I think if you spend some time getting used to committing more frequently you may find it much more flexible and much safer and more forgiving than trying to keep everything straight in the working tree alone. If you have uncommitted changes in X, and you want in Y instead, then you can: $ git checkout Y $ git commit -am "config changes" If you get merge conflicts, or if you want to keep the change in X too, you can: $ git commit -am "config changes" $ git checkout Y $ git cherry-pick X The first case is fewer steps than stash, the second is just as easy as stash. Popping a stash and cherry-picking a commit have the same process if there's a merge conflict, except that with a commit, you have undo capability if you merge incorrectly, and you have a safety net if you get lost or screw up in the middle of the resolution. With stash, you're stuck with a bad merge, and if you lose your stash -- and it happens -- you have to hunt for it by searching for dangling blobs. You made a big deal out of having to create and remember and lookup hashes, and I don't see that as being an issue at all, and it's not a problem in my experience. You're comparing this to stash, after all, and stash only works on uncommitted changes, so there is never a case where you'll need a hash, because the stash equivalent is always at the tip of the branch, you can always use the branch name instead of a hash.

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.

projektir 10y ago
> No. Your WIP commit will always land at the end. Anything you pull will rebase to before your WIP commit. I was talking about the non-rebase version. You didn't address the rest of my post: there are other cases. This will work for that particular case, but it's not a general-purpose solution. If I have branch X with config changes, and coworker wants me to switch to branch Y but I still want my config changes, what do I do?
- dahart 10y ago
  Stash is not a general purpose solution. You don't ever need to stash. There is nothing you can do with stashes that you can't do with core git commands, and the reverse is not true. Git could eliminate the stash command tomorrow without any loss of functionality. What if you already committed your config changes to branch X, and your coworker wants them in Y? What if you you're working along and you have commits, staged changes, unstaged changes, and you need to branch 3 commits ago instead? Stash doesn't help with either of those, and the workflow I'm advocating - just use commits and branches for temporary work - does. Stash really only helps you if you don't like to commit often, and you spend most of your time with unstaged changes in your working tree. Nothing wrong with that, if that's how you like to work, but I think if you spend some time getting used to committing more frequently you may find it much more flexible and much safer and more forgiving than trying to keep everything straight in the working tree alone. If you have uncommitted changes in X, and you want in Y instead, then you can: $ git checkout Y $ git commit -am "config changes" If you get merge conflicts, or if you want to keep the change in X too, you can: $ git commit -am "config changes" $ git checkout Y $ git cherry-pick X The first case is fewer steps than stash, the second is just as easy as stash. Popping a stash and cherry-picking a commit have the same process if there's a merge conflict, except that with a commit, you have undo capability if you merge incorrectly, and you have a safety net if you get lost or screw up in the middle of the resolution. With stash, you're stuck with a bad merge, and if you lose your stash -- and it happens -- you have to hunt for it by searching for dangling blobs. You made a big deal out of having to create and remember and lookup hashes, and I don't see that as being an issue at all, and it's not a problem in my experience. You're comparing this to stash, after all, and stash only works on uncommitted changes, so there is never a case where you'll need a hash, because the stash equivalent is always at the tip of the branch, you can always use the branch name instead of a hash.