These are mostly straw-man arguments. People don’t generally rebase published history unless there are mitigating circumstances. It’s not common, and it’s not r

These are mostly straw-man arguments. People don’t generally rebase published history unless there are mitigating circumstances. It’s not common, and it’s not recommended. Rebase is for cleaning local history before pushing it to anyone else. Similarly, git does not squash commits upon merge unless you ask it to, that is not some idiotic thing that just happens. BTW, Fossil has commands called “shun” and “scrub” that do effectively rewrite history. Every version control system has them, because you have to have them. Being on a high horse over rebase is 1- not going to change rebase, and 2- makes it seem like you don’t fully understand git, and it’s design decisions and goals, therefore not qualified to opine on it. See Chesterton’s Fence. All of this is mostly irrelevant to getting coding done. Wanting immutable history is fine, if that’s what you want. I’ve never heard a compelling reason to need it, and it’s not one of git’s goals, and never was. (Nor was it a goal of any other version control system either, not of svn or p4 or hg or source safe…) Git is version control, and it does what it was designed to do which is keep multiple versions around, let you share versions with other people, and be a safety net against code loss. I can’t think of a single time in my decades of professional software career where it mattered that someone edited their local history before pushing, and/or didn’t preserve some strange sacrosanct history of the exact order every line of code was written. I don’t have anything against holding this goal, but I’m unconvinced that it’s relevant.