Git made the only choice a popular VCS can make. History rewrites will exist, period. If you're opposed to history rewrites, then git gives you the tools to ensure the repos you control are not rewritten, and that's all it can do in a world where people have control of their own computers.
If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil.
Another user in this thread linked to jj [0], an alternative git client that does some pretty weird things. For example, it replaces the working tree with a working commit and commits quite often. I like git and that seems weird to me, but I'm not offended, people can do what they want on their own computer and I have the tools to ensure repos under my control are not affected. That's all I can hope for, and I'm happy that jj makes git more usable for some people.
It's more than inevitability to me; on some level I would almost say that "history" in Git is the wrong name. I've had conversations with Fossil devs before where they referred to rewriting history as a "white lie" and I just don't agree with that framing, I don't think it's a lie at all.
Git's history can correspond to actual history in reality and that can be a useful way to add accountability to a project (although of course as you say, you have no control over history coming from someone else's computer). But Git's "history" doesn't have to correspond to actual history in reality, and very often that's not how I'm using it. So I don't think when I rebase I'm lying because I don't believe I'm making any claim at all about the physical reality of how the code was written. I'm organizing feature commits on a timeline.
To me it's a little odd to look at that and to say "you're trying to change history." No, I'm not, I'm not saying anything at all about history when I do a rebase. I am grouping code together into logical units and putting them on a timeline so that they make sense when read sequentially. That's all I'm doing. If I came to you and said "this rebase perfectly represents the development history", sure that would be a lie. But I'm not saying that, and I don't think it's inherently the job of a VC system to claim that. I think the most important job of a version control system is to... well... control versions, and immutably showcasing a record of how the project was built is a secondary concern.
:shrug: At least the way I use VCs, I guess other people's millage may vary.
> then git gives you the tools to ensure the repos you control are not rewritten
I might betray my ignorance here, but what tools are those?
If I host a git repo, then I can obviously ensure that any branches on the origin are never rewritten. But how can I ensure that people who submit pull requests have not rewritten their history?
> I can obviously ensure that any branches on the origin are never rewritten
That is all I meant. As you say, people can still rewrite their own history on their own computer before submitting it.
We could get philosophical about what "history" is. If I press backspace am I rewriting history? What granularity are we talking here? If I make change X by frequently committing and then squash, have I rewritten history? If I make the exact same change X with one big commit at the end (no squashing), have I not rewritten history? Whether or not I rewrote history the pull request at the end is the same. Or what if I'm using jj which amends a "working commit" hundreds of times, have I rewritten history?
Ultimately the division of changes into commits is a matter of authorship, a creative endeavor. I'd prefer to do this creative work with whatever tools I choose, but if you force me to never squash, I can still achieve the same creative output using other tools or by altering how I work. At no point were commits ever an actual history, they were always a presentation of the history the author chose to present.
(I've rambled on here, most of this isn't meant as a direct reply to you.)
On my team we use pre-commit[0] a lot. I guess I would define the history to be something like "has this commit ever been run through our pre-commit hooks?". If you rewrite history, you'll (usually) produce commits that have not been through pre-commit (and they've therefore dodged a lot of static checks that might catch code that wasn't working, at that point in time). That gives some manner of objectivity to the "history", although it does depend on each user having their pre-commit hooks activated in their local workspace.
If Fossil ever becomes as popular as git, people will create software that allows history rewriting in Fossil.
Another user in this thread linked to jj [0], an alternative git client that does some pretty weird things. For example, it replaces the working tree with a working commit and commits quite often. I like git and that seems weird to me, but I'm not offended, people can do what they want on their own computer and I have the tools to ensure repos under my control are not affected. That's all I can hope for, and I'm happy that jj makes git more usable for some people.
[0]: https://github.com/martinvonz/jj