I interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using. Otherwise I totally agree with you; git was d

I interpreted the part you quoted to mean avoid rebase once you push into a public stream other people are using. Otherwise I totally agree with you; git was designed with rebase use in mind. There’s a misleading meme about rebase being a “lie” that just can’t die soon enough. It’s done more damage than good. The problem is that it’s specious - tempting, persuasive, and easy to believe, even if it’s wrong and/or misguided - and the narrative of rebase being bad is supported and spread by respectable people like SQLite’s author. What some people don’t consider is that the story about rebase being harmful is frequently a sales pitch for a different DVCS entirely - the message isn’t to not rebase, it’s to not use git. Don’t rebase public/main branches (except in emergencies). Do rebase your local work before push. If using rebase in feature branches, use it (along with communication) in inverse proportion to how many other people are using it, because they have to force pull and so nobody stomps on anyone’s work. The idea that the exact order of every character typed is sacrosanct and should be immutable is strange. But there is a valid point behind some of the rebase criticism, which is that git does not have the best facilities for controlling how history is presented, and if it did, rebase might not be needed to the same degree that it is now. Some DVCSs are designing ways to have a plumbing history, and a separate porcelain history, to use git terminology. That seems like a genuinely good idea, and maybe in the future git can incorporate something like it.