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 whe

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.