3 ms·
> I call it "lying", since the purpose seems to be to deceive the reader about what actually happened. Do you have any better reasons to avoid rebase that don’
by dahart 6y ago
> I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.
Do you have any better reasons to avoid rebase that don’t depend on your own negative interpretation of git’s design intent, an interpretation that contradicts git documentation?
You could be focusing on positives instead of trash talking. You could be talking about the interesting idea of providing multiple views of history, one un-editable for details and one editable for presentation. That’s interesting and useful. Instead you choose to take cheap shots at a system that was designed differently than your ideal, without acknowledging its intent. You are breaking Hanlon’s razor and consciously choosing to assuming malice... for something that has a written history of discussion about why it exists.
Are you aware that rebase openly advertises the fact that it reorders commits, and was designed that way intentionally? Are you aware that git openly makes zero guarantees about the order of transaction events, intentionally, to allow me to have control over my presentation? Are you aware that rebase is primarily used on local commits before push, and not often used after push?
I would speculate that you are aware of these things, and not simply ignorant about git. If so, that means you are lying here and now, if not it means you don’t know what you’re talking about. I think you know git’s design intent, so it seems like you are intentionally misrepresenting the design intent of rebase. The only deceit here is coming from you, ironically.
- mscrnt 6y agoExcept 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.
- dahart 6y agoWhy 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.
- minusf 6y agonah, rebasing is white lies. everybody is in on it. not all lies are malicious. rebasing is "rewriting history". where I'm from "rewriting history" is lying..
- dahart 6y ago> not all lies are malicious 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.
- mscrnt 6y agoIn 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.
- dahart 6y ago