I frequently have a commit history that looks something like:
* Add call stub to Foo, add calls to the stub where needed
* Beginnings of implementation, seems really friggin slow right now.
* Ok, back to square one, need calls to X, Y and Z, can be chained together, wrap behind the call we actually need.
* Final implementation
Which I then may leave comments in the code about the obvious approach that didn't work, or why it is the way it is. I then squash this into two commits, first one covering the implementation added to Foo with an appropriate descriptive commit message and a second commit after it that actually uses the new implementation.
Most of the incomplete commits aren't necessary, but we only develop on topic branches and I have a desktop I use at work and a laptop that travels to and from work with me (in case of deciding to work at a coffeeshop, or want to kick back, etc.). The ability to push not-yet-done work to my topic branch makes it available to either computer and the committing when halfway through because it's time to not be at the desk can easily be fixed with squashed commits.
Most of the incomplete commits aren't necessary, but we only develop on topic branches and I have a desktop I use at work and a laptop that travels to and from work with me (in case of deciding to work at a coffeeshop, or want to kick back, etc.). The ability to push not-yet-done work to my topic branch makes it available to either computer and the committing when halfway through because it's time to not be at the desk can easily be fixed with squashed commits.