[Tibbes]

"If you ever want to git-bisect your code-base to track down when you introduced a bug then you'll be very thankful that every commit is functional and passes your test-suite"

I agree that this property is very useful, but I disagree that it it is necessarily implied by the workflow as described in the article. By using "git add -p", he is constructing a tree that probably never actually existed during development - hence there is no guarantee that it works and passes the tests.

I strongly agree with you that a clean logical progression of commits is a good thing (especially for code review). However, making sure that each stage works and passes the tests takes extra discipline.

[kderbe]

The author runs his tests after his partial commits. He does this by stashing the remaining changes, testing the newly-committed code, and then continuing to make partial commits. Here's the example in the article:

        % git stash
        % make test
        ...
        OK
        % git stash pop

Also keep in mind that the initial tree contains WIP commits that are unlikely to work or pass tests, so reordering commits can hardly make things worse.