> Why? What need is there to preserve the commit history, and why is it superior?
Being able to lie about what changes took place, what methods might have been tried by scrapped, and other small things possibly considered "noise at the time" often end up being valuable clues during maintaining that code years later.
>Are you very familiar with git and understand what workflows the git history rewriting tools were intended for, and how they’re typically used and supposed to be used?
Yes, intention for the tools, and the way people end up using them are not 1:1.
The potential for mistakes and information hiding is higher when you can rewrite history.
> Git only ever advocated for rebase, squash, and cherry pick for local branches that haven’t been pushed or shared yet.
Just because they advocate using it the right way, they enable using it the wrong way so people will use it the wrong way, and that's a guarantee of humans.
>It is arguably not even “history” until you publish it.
If you committed it, it's history.
If you're trying to make the claim of local history having no utility, thats a different argument imo.
> There have always been strong warnings about doing those things to published histories. It’s bad form generally speaking to do it (rebase or change history) to a published branch that more than 1 person is using for any other reason than extreme necessity, such as cleaning up security accidents where someone pushed keys or info they weren’t supposed to. And for exactly that reason, all the opinionated DVCSs that claim to consider history “sacred” actually offer the ability to easily rewrite published history, including Hg and Fossil!
This shows your lack of knowledge and XP with other DVCS and your assumptions there.
> Git’s ability to rewrite local history is pretty important for (1) encouraging a commit-early commit-often workflow where the local repo is a safe space,
No, I can do that with out rebase or cherry pick.
(2) cleaning up your work to make it presentable and semantically organized before sharing/publishing, and
Bad practice. Your history is useful metadata about what happened. I don't want a single commit in your PR. I want to see the reason it took X days.
(3) allowing real-world workflows where people didn’t plan every single feature branch in advance but happened to end up working on multiple things and committing them first.
>
That's a nonsense claim.
> A version control system should be, first and foremost, a safety net that simply backs up any work you do without judgement.
Then use Dropbox?
>Personally, I consider the idea that commit history is sacred to be dogmatic and unnecessary.
I think this shows a lack of XP in maintaining older systems.
>I’m open to the idea that it might help prevent a few specific types of accidents here and there, and it might be fair to argue that offering tools to groom the history’s presentation, separately from the log of commit activity, is on average a slightly better idea than having to actually reorganize commits before pushing them. Maybe that didn’t occur to git devs before it was released, or maybe it did and they decided it wasn’t going to help anyone and just add confusion to have two separate timelines. I don’t see any reasons justifying calling git’s design a ‘mistake’, and there seems to be evidence that most people are fine with git, and that for whatever reason the DVCSs that reacted to git in 2005 by immediately trying to fix some of git’s perceived issues didn’t ultimately fix the problem well enough to gain traction.
Yes, history grooming is purely something for a UI to do.