This article is pretty much the correct response to the pull --rebase discussions. No need for it -- you should be using a branch.

But I'm not sold on no rebase at all: a common workflow for me is commit often while getting something working, then rebase 4 or 5 commits into a presentable unit (using magit). I have to admit I hadn't noticed that the timestamps were preserved by rebase. And there doesn't seem to be a rebase option that tells git to create new timestamps with chronological order matching the new commit order? I could use `filter-branch`, but it seems heavyweight.

One other criticism of the article:

> A soft reset back to origin's HEAD, and then re-commit your work

That leads to errors: if you've added new files, you may very well forget to add the same set again after the soft reset.