Except none of that refutes the fact that changing history is lying irrespective of the motivation behind the change. You can rephrase it however your sensibilities like, it won’t change that fact.
Why are you calling it “lying”? That’s a framing with a value judgement that is accusing people who rebase of being malicious. Do you believe use of rebase is malicious?
Who are you lying to, if the other people on your team expect your merges to be rebased before you push?
What history is being lied about, if no one every saw if before it was pushed, and it is never rebased after being pushed?
Rebase is not intending to trick someone, it is not concealing a truth that needs to be otherwise preserved. Rebase is not hiding something that should not be hidden. Rebase is for cleanup and fixing mistakes.
Please stop using inappropriate words. It’s completely fine to preserve your messy edit history. It’s completely fine to want to preserve your mess. But it is not “lying” to clean it up before you push.
It’s funny you suggest I’m rephrasing it, when you are the one using different (negative) language than the git manual.
The Fossil manual is pretty clear about calling it deceit. “By discarding parentage information, rebase attempts to deceive the reader about how the code actually came together.”
> where I’m from “rewriting history” is lying...
What history? Rebase is normally used before push. Rebase is used before it’s “history” to someone other than yourself.
In the event it's done before pushing, it's still lying, albeit to yourself—it is falsifying the record of what actually happened. The clearest way of conveying this is with the word "lying." Perhaps "falsifying" or even "manipulating" would also appropriately convey this fact. And conveying facts accurately is arguing in good faith. Not to mention it is not only ever done while contained to the local checkout, in which case it is not just lying to yourself. Being triggered over trivialities is one thing, but to be triggered over a factual representation of the feature that comports with Git's own notion is something else. Try not to let it keep you from trying something that may productively fit your workflow—it could make life simpler. And it appears that you're attaching the value judgement—no-one is accusing people of being malicious. Instead, we are truthfully reporting what has happened; when you rebase, you are presenting events not as they historically occurred—but how you would prefer it had occurred. Nonetheless, Fossil enables curating the presentation of that history however you, or I, or Thomas or Jane would like; while keeping a true and unfalsified historical record. It's the best of both worlds—you're not forced to recount your mess and mistakes every time you look at the log. But for auditing purposes, the real timeline is still intact.
Why not just focus on the useful idea of separating presentation from commits, as a +1 bit of design thinking and evolution beyond git? I don't get this pretend crusade for nothing more than facts and truth, when the value judgement in the Fossil docs is thick and plain as day.
I don't even care that Fossil is attacking the competition, really. I am a huge fan of SQLite. I just wish this silly "lying" argument would go away. It does not put Fossil in a good light. It does not make a meaningful contribution to understanding version control workflows. It does not give git (or any other VCS) the benefit of the doubt or it's due credit in the context of it's own design decisions, even if those design decisions are inferior by today's standards or in Dr. Hipp's opinion. But, it's clear I didn't make any progress here, I'll just think about why I'm not being persuasive and try again later. This claim about lying would be just as "true" but even sillier applied to Perforce or Subversion or RCS or SCCS... think about it.
That's on you that you take it as a value judgment of your or anyone else's character. It's quite literally an accurate description of the rebase feature and the result of its use. And criticism of Git's design philosophy should not be misconstrued as a pretend crusade or personal attack. I presume the lead dev of Fossil and SQLite places a high price on auditability for not only personal philosophical reasons but professional necessity. So highlighting the foible to facilitate falsifying the historical record of a software development lifecycle is fair. But to get so vexed and try to persuade others that an emotional response to an accurate description of a software component is always going to be a tough sell. Instead, maybe try Fossil and see if it is in fact unsuitable to your workflow, then try a different persuasive approach on why Fossil is wrong. Because on this point—it isn't.
Who are you lying to, if the other people on your team expect your merges to be rebased before you push?
What history is being lied about, if no one every saw if before it was pushed, and it is never rebased after being pushed?
Rebase is not intending to trick someone, it is not concealing a truth that needs to be otherwise preserved. Rebase is not hiding something that should not be hidden. Rebase is for cleanup and fixing mistakes.
Please stop using inappropriate words. It’s completely fine to preserve your messy edit history. It’s completely fine to want to preserve your mess. But it is not “lying” to clean it up before you push.
It’s funny you suggest I’m rephrasing it, when you are the one using different (negative) language than the git manual.