I've thought about using the index like that before, but the problem you run into is if you decide you need to go back to, or even just look at, some change several adds ago the data is gone. The index feels like I've just copied some text in an editor: the more time that passes before I use it the more likely I am to either have to check what is there or accidentally overwrite it by copying something else.
My general philosophy right now is that I should only push one commit for each complete feature or bug fix, which wasn't really reasonable in old VCS systems. That lends itself to making micro-commits for almost anything and then using rebase -i to clean up the mess into a single commit. I've recently been experimenting with tagging the pre-rebase commit so that if I want to look at the development history I still can. I use git-stash if I'm in the middle of something and need to change branches for a few minutes, but aside from speed there's no reason it couldn't be a commit as well.
Is this article useful for someone who doesn't know git? It would be helpful to have summaries/prerequisites as a first post... As is I can't bring myself to read it.
My general philosophy right now is that I should only push one commit for each complete feature or bug fix, which wasn't really reasonable in old VCS systems. That lends itself to making micro-commits for almost anything and then using rebase -i to clean up the mess into a single commit. I've recently been experimenting with tagging the pre-rebase commit so that if I want to look at the development history I still can. I use git-stash if I'm in the middle of something and need to change branches for a few minutes, but aside from speed there's no reason it couldn't be a commit as well.