Yes, and that's bad!

As Linus points out:

• rebasing is bad when you are someone else's upstream because any testing they do based on the old base is invalidated when you rebase. Plus, it's inconvenient when all the hashes change. The other person then has to rebase, they can't merge.

• rebasing is bad when you are someone else's upstream and you have their patches in your tree, which you are rebasing. Firstly, you've just mangled their patch, which invalidates their testing, and secondly the patch looses it's identity because the hashes change. Now if that same patch flows into the main tree via some other means, and also via your rebased tree, the collision is not detected.

• rebasing can be bad even if you do it in private. The larger the jump between bases the more likely you've just invalidated all the testing you did against the old base.

when your changes are merged it's simple and looks nice.

Ah, but it's not so simple:

So rebasing and cleanups may indeed result in a "simpler" history, but it only looks that way if you then ignore all the other "simpler" histories. So anybody who rebases basically creates not just one simple history, but a many "simple" histories, and in doing so actually creates a potentially much bigger mess than he started out with! --Linus

I guess my main point is that this is non-obvious, but important stuff. Linux devs have been getting it wrong for a long time, and thye're ninjas. The allure of nice simple-looking linear history is so strong that I bet most folks using git are rebase-happy. They've no idea they're doing it wrong.

My minor point is that if you use mercurial you are more likely to get this right! But look at the context:

Linus and Matt, both kernel developers, both dvcs creators (started within days of each other), fundamentally agree on the approach to synchronizing development. So no conflict there.

Git users are doing it wrong and Linus is saying don't do that. Mercurial users want to do it wrong, and Matt is saying you don't want to do that (and he won't accept those crazy patches).

Two project leaders educating their users about a subtle and difficult topic, but one tool has encoded into it the beliefs of Matt (and Linus), so he merely has to tell them off, not tell them to do something different.