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 ."

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

> "git checkout -" switches to the previous branch.

OH, that's very nice, I want that. Guess I need to upgrade my git. Okay, that invalidates my entire previous post. Sorry! ;)

So, if you made changes on X but wanted them on Y...

The thing about the "git checkout Y" is that there's no harm in trying, and it'll work most of the time. If it does work, you only have to commit, and you're done in less time than it takes to stash & pop.

If you're just not the gambling type, here's one way to avoid branch ping-pong. I'm sure there are others.

  $ git checkout -b Z
  $ git commit -a "config changes"
  $ git checkout Y
  $ git cherry-pick Z
  $ git branch -D Z

I admit that's a tiny bit more work than with stash, in this case, but it's safer than stash, that's why I prefer it and advocate it. It is demonstrably harder to screw up if bad things happen in the middle. This workflow is also more general - you can use it if you have commits in X already. Stash doesn't help you there.

I've personally witnessed too many stash accidents. BUT, if you are comfortable with using fsck if anything goes wrong, you really have no reason to consider my opinion at all.

I'm painting a picture that is more anti-stash than I actually am. My main safety concern with stash is how it's implemented, not how easy it is. The git authors could have used something like the above commands under the hood to implement stash, but they chose to circumvent the reflog for reasons I don't know, and that choice leads to frequent accidents. Git is supposed to be your safety net, not something that gets you into trouble.

That said, a lot of people seem to think stash is many times easier than the alternative, and I think if you really look at the alternatives fairly, using commits is most of the time not more difficult than stash, and occasionally one or two extra commands. It's just not that hard to avoid stash, and there are significant benefits.

What's the way that one screws up with stash that doesn't happen with other approaches? I don't think I've seen stash accidents, though most of my colleagues don't seem to use stash much. If an attempt to pop conflicts, can't you just abort it?