[rlpb]

It all depends on what you use git for. git is a great tool for revision control, but it is also a great tool for managing your own work, where it becomes closer to being an editor function than a revision control tool.

When I wrote an essay at school, I was taught to write a draft first, and sometimes a second draft. I typically wasn't expected to hand the drafts in.

When I write code in an editor, I don't save a history of every keystroke, yet I do commit often. In a way, I formalise the undo function of my editor slightly, but it becomes logical-change centric rather than keystroke-centric.

If you treat git as a tool to develop your own work as well as to manage the project revision history, then it makes perfect sense to draw the line somewhere. For work before that line (eg. experimental commits or reworking a patch for upstream submission), use rebase. For things on the other side of the line, use merge. Ruling out one side of this line entirely is just counter-productive.

Another example: git was written for open source projects. It is typically expected in these environments that patch submissions are coherent and complete. Nobody wants to see the mistakes that you correct and then fixed; they want to see patches that make sense and are easy to review. Rebasing is great for this.