With svn you really do not want to do this since in my experience you can only work at one thing at a time per checked out directory. Instead you have to write it down or try to remember.
svn diff >patch-saved-changes
svn revert -R .
(work work work)
svn patch <patch-saved-changesBut what I was specifically referring to is the -p flags of various git commands (stash, reset, add, checkout, ...) so you can interactively only stash away what you wish instead of the entire working directory (or an entire subdirectory of it).
The tools are more powerful, but they're also correspondingly more complex, and the net value is in my experience negative.
People simply feel more productive as the number of knobs they're turning increases. However, SCM is the least important knob in my day-to-day development. What matters to me is turning around quick changes with associated unit tests and ultimately committing code that works the first time. The less I think about SCM knobs, the sooner I can move on to the next piece of actual work.
Git stash is a killer feature that every developer can relate to, and highlights git's power.
Let's say you have 3 bugs to fix. In SVN you might work on them 1 at a time (start to finish -- hopefully no blockers!), or descend into madness and try to work on all 3 simultaneously. In git, you'd make 3 branches and work on each separately.
Oh, a hotfix came along while you're halfway through a bugfix? In SVN, you cringe: do I manually copy my changes somewhere else and revert? Ugh.
In git, you just make another branch from your clean master, do the hotfix, and pull that change into your bug branches at your leisure. In svn, this branching is theoretically possible, but not used practically -- they are too cumbersome and manual (you need to track what changes went where, and could accidentally apply them twice).
I've written more about it here, if you're interested:
http://betterexplained.com/articles/intro-to-distributed-ver...