> But you aren't; history is as much about where you came from as where you are now. No. That's clearly something you are failing to understand. Commit history

> But you aren't; history is as much about where you came from as where you are now. No. That's clearly something you are failing to understand. Commit history is not chronological. Commit history is ordinal. I make my commits, and I say where they should go and in which order they should go. Try to understand that. > Because merges aren't noise, they are fallible events just like manual changes. You're not even paying attention to what you are saying. If you interpret merges are "fallible events" then what's the point of pushing a "fallible event" to a shared repository when they are irrelevant to describe your changeset? The only purpose they have is to make sure your feature branch can be merged back to mainline with the latest changes in mainline. Why introduce a "fallible event" for that? Isn't it far simpler if you just reapply your commits on top of the branch, and leave those "fallible events" out of the commit history? Moreover, look at the silliness of it all. What prevents anyone from manually replaying a commit history on top of another branch? Should that be prevented too? Should support for squashed merges be removed too because they lose a reference to the origin commit? What's exactly the point you're trying to argue? > Deleting data is opinionated, preserving it leaves it up to the reader to judge. Try to understand this: you read what I write. No more, no less. > In my, uh, decade or so of using Git, every single avoidable problem that I have seen people have with Git turns out to originally come from rebasing. So what? Are you also going to argue to ban furniture because unsupervised toddlers can bang their heads on it? Do you know who doesn't waste time posting remarks on rebase? People who use it all the time and don't have a problem with it.