6 ms·

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

> 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.
- lmm 10y ago
  > $ git commit -am "config changes" > $ git checkout Y > $ git cherry-pick X Sure, but then I also have to do: $ git checkout - $ git reset --hard HEAD~1 $ git checkout - which is a bunch of faff compared to the stash approach. (side complaint: why doesn't "-" work for merge/cherry-pick/reset like it does for checkout?)
  - dahart 10y ago
    Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows. > why doesn't "-" work for merge/cherry-pick/reset like it does for checkout? I don't know what a single dash does for you. On my git, I get a command line error with a single dash. Maybe you were thinking double-dash? A double-dash is used to separate flags to your git command from path arguments, just in case a file you put on the command line starts with a dash. (Pro-tip: don't name files that start with dashes.) Running "git checkout -- ." at the top level of your repo will do the same thing as "git reset --hard HEAD". Merge, cherry-pick and reset all work on refs, not on paths, so when you add a -- to one of those commands you may get an error like this: fatal: Cannot do hard reset with paths The -- is optional to checkout, if the path is unambiguous. You can reset unstaged changes from your repo root by using "git checkout ."
    - lmm 10y ago
      > Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows. I accidentally made changes while on X when I wanted to make them on Y. I don't want to just "git checkout Y" in case that conflicts. If I do as you suggested and commit them (on X) and then cherry-pick that commit onto Y, I then have to go back to X to remove the commit I made, otherwise I have the changes on X as well. > I don't know what a single dash does for you. On my git, I get a command line error with a single dash "git checkout -" switches to the previous branch. Which is great, but it's frustrating that I can't do e.g. "git merge -" to merge the previous branch - logically that should be the same kind of thing.

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.

lmm 10y ago
> $ git commit -am "config changes" > $ git checkout Y > $ git cherry-pick X Sure, but then I also have to do: $ git checkout - $ git reset --hard HEAD~1 $ git checkout - which is a bunch of faff compared to the stash approach. (side complaint: why doesn't "-" work for merge/cherry-pick/reset like it does for checkout?)
- dahart 10y ago
  Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows. > why doesn't "-" work for merge/cherry-pick/reset like it does for checkout? I don't know what a single dash does for you. On my git, I get a command line error with a single dash. Maybe you were thinking double-dash? A double-dash is used to separate flags to your git command from path arguments, just in case a file you put on the command line starts with a dash. (Pro-tip: don't name files that start with dashes.) Running "git checkout -- ." at the top level of your repo will do the same thing as "git reset --hard HEAD". Merge, cherry-pick and reset all work on refs, not on paths, so when you add a -- to one of those commands you may get an error like this: fatal: Cannot do hard reset with paths The -- is optional to checkout, if the path is unambiguous. You can reset unstaged changes from your repo root by using "git checkout ."
  - lmm 10y ago
    > Huh? I don't get what you're doing there, or why you reset unstaged changes 3 times in a row... If you're trying to get rid of a commit, a single reset --hard will do. But why are you trying to get rid of a commit, and how is this more work that using stash? If you have unstaged changes you don't want, you have to reset either way, this is orthogonal to comparing stash vs no-stash workflows. I accidentally made changes while on X when I wanted to make them on Y. I don't want to just "git checkout Y" in case that conflicts. If I do as you suggested and commit them (on X) and then cherry-pick that commit onto Y, I then have to go back to X to remove the commit I made, otherwise I have the changes on X as well. > I don't know what a single dash does for you. On my git, I get a command line error with a single dash "git checkout -" switches to the previous branch. Which is great, but it's frustrating that I can't do e.g. "git merge -" to merge the previous branch - logically that should be the same kind of thing.