Agreed. In particular “Rebasing is lying about the project history” is misleading and frankly, just downright lame hyperbole. I actually want to try Fossil, but this text is so dishonest and hyperbolic, it’s off-putting and preventing me from trying Fossil. This feels like a sign that Fossil might not be focused on real world user needs.
It’s not uncommon to bump into this claim in threads about git, I don’t think the Fossil devs came up with this idea, but they sure are running with it. This is an argument whose time has passed and needs to die. It’s not helpful.
Please @Fossil devs, come up with better and more honest reasons to compare Fossil to git. If I don’t have to rebase again, that’s great! If Fossil avoids merge conflicts more often, and handles merge conflicts better, absolutely fantastic.
But, please, come on. Rebase is “lying” exactly just as much as hitting backspace is “lying”. Am I lying if I fix a typo or a bug before I commit? Do you really want to preserve all keystrokes ever typed on your keyboard during development? Does Fossil actually capture all keystrokes? If not, then are you sure Fossil is not lying about development history by your definition? Being able to clean and organize your development history before you share it with others is an intentional feature, not a bug. Attempting to claim a moral high ground over what is purely a technical and workflow issue is making Fossil look ignorant to me, it’s doing the opposite of what you want.
I consider a version control system to be a history of a project. If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact.
The history Git and in Fossil is only precise to the transaction level. A key-stroke or backspace is not a transaction. A single iteration of the edit-compile-test cycle is not a transaction. A transaction is created by the "commit" command. Git and Fossil make no record of the stuff that happens in between two commits. They only record what is in each commit. So you can backspace and edit and change all you want to before typing "commit". But once you type "commit", all that you've done since the previous commit becomes part of the permanent record. Rebase violates that constraint. It changes the permanent record. Rebase makes the repository say that the sequence of commits is different from the order in which they actually happened.
You can call that whatever you like. "Telling a compelling story." "Generating a clean history." I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.
It is useful to have a simplified overview of project history, to aid the reader's comprehension. There is no sin in this as long as you are truthful to state that the simplified history is in fact a simplification that skips or revises some of the messy details of reality. The alternatives to rebase that Fossil provides do exactly that - they suppress the unimportant details of the history to provide a simplified and more readable history. The difference is that the original, truthful history is still provided, for auditing and for those who care. In other words, the repository reports both "what we should have done" and/or "the best way to think about what we did" in addition to "what actually happened".
I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative. But I think that a source code repository should be a true history of a project. If you view a source repository as a true history, as I do, then rebase is a tool for lying about the history.
> I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.
This is exactly the kind of dishonest hyperbole daheart mentioned.
The purpose isn‘t to deceive the reader. Does the reader really need to see the "tmp" commit I made when switching from my desktop to my laptop? I do not think so, and squashing this commit is not intended to deceive anybody. Your comment on the other hand…
In my view, what I am doing with rebase is creating project history, not changing it. The history becomes immutable and "the truth" once the feature branch is merged.
> I think that a source code repository should be a true history of a project.
You repeatedly claim this without justification. Seems like many people do not see the value in "WIP" and "tmp" commits and failed design decisions littering history.
You do provide good reasons for why this isn‘t useful though:
> So you can backspace and edit and change all you want to before typing "commit"
So you agree correcting mistakes is useful, and not everything should be recorded.
> It is useful to have a simplified overview of project history, to aid the reader's comprehension.
> I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative.
Exactly.
Consider "I ate a sandwich." vs "I though about eating a watermelone (typo), but when I opened the fridge, I changed my mind and decided to make a sandwich instead. During the process I dropped my knife on the floor and had to clean it. Then I ate a sandwich."
The second one is a much more detailed and truthful account of what happened, yet it does not provide any value. The first, much shorter and easier to follow, history conveys exactly what I wanted to tell you: What I ate.
> If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact.
I use rebase to clean up the history of my feature branches before merging to release branches.
In that sense I don’t see a moral difference between not committing my work at all until it’s complete and rebasing. It doesn’t seem like any more of a rewriting of history than just editing text before each commit.
The nice thing about rebasing is that future readers don’t need to see the 20 commits I created titled “wip” just so I could back up my work at the end of the day or push to a test server.
There is a better way to achieve your goal of removing uninteresting commits from the project history. Rather than explain it here, I will write an article about it and post it on HN. Stay tuned.
My philosophy is that the true transaction event and accurate immutable history of the project is the artifact built for release (in our process, the merge to master drives this and therefore commits to it map to the transaction event). The stumbles and trips along the way are irrelevant keystrokes that get backspaced / rebased out.
Big fan of SQLite here (thank you!), and very interested in Fossil as well.
I never understood why people want to change commit history in Git, so for me it won't be an issue to not have that in Fossil.
Having said that, one point of feedback on the "lying" part: I personally interpret that type of negative phrasing as pointing at a different tool and saying: "Look! They're doing it wrong!"
You make amazing tools, man! There is no need to speak negatively about the behaviour of other players if you're a fantastic player yourself. I'd personally just mention: "Git allows you to change history. Fossil is never going to allow changing history, because that could cause issues X, Y and Z. If you do need to change history for some reason, by all means try something like Git." Keep it factual, and get right back to pointing out what makes Fossil great.
I love how SQLite doesn't downplay any alternatives, it just says: "Look at me. I'm awesome. But if you need to do <unsupported thing>, you probably don't want to use me."
It would be great if the Fossil website had that same awesome attitude.
TL/DR: Random guy X that never created a successful product gave marketing advice to the person who created one of the most successful products of all time. Random guy X is an idiot.
> There is no need to speak negatively about the behaviour of other players
I don't interpret it as a negative statement about Git or any other version control system. I interpret it as a statement about use of the term "project history" after rebasing. I agree with him, because the phrase "history of the project" implies it's the history of the project, and that's simply not what you have. If you order a cheeseburger and they give you a chicken sandwich, maybe it doesn't bother you since you like both, but it would indeed be lying if someone asks what you're eating and you say it's a cheeseburger.
What history, exactly, is being preserved? If I fix a bug before I commit, then I’m okay. If I commit the bug, then commit the fix, then squash, all locally on my own machine before I push anything, I’m “lying”?
You don’t want the ability to edit your own mistakes before showing them to other people, even if you find them before you push?
Fossil is not capturing my pre-commit keystrokes, so I can write code and delete it without turning it into a ‘transaction’. Is that lying?
What’s sacred about my local branch before I push? In practice, nobody rebases things in public branches except by accident or to fix big mistakes. Rebase is almost entirely a local pre-push workflow. Why should I be preserving my local pre-push history, and why are you calling that “project history”?
If “project history” is so sacred that all commits should be declared immutable, how do you suggest fixing accidents like someone checking in SSH keys? Is it impossible to fix security accidents in Fossil? If so, is that good?
Why is the word “lying” being used instead of saying something like “the project’s history of transactions is being changed”? Do you think the phrasing is not intentional? Do you believe it’s good faith to accuse tool writers and tool users of being deceitful for just using a tool the way it’s designed? Do you believe the write up on rebase is impartial?
I think (a) all of this was explained clearly in the post by SQLite (Fossil creator), and (b) you're overly sensitive to a disagreement about the definition of terms. I agree with him. You don't. That's fine - no kittens will be put to death depending on who is right.
Hehe, true, no kittens will die. I'm just debating, so don't get overly sensitive just because I disagree.
I don't feel like it was clearly explained, which is why I asked those questions. There's no distinction between local private history and public history shared with others, there's no explanation for the arbitrary line drawn on transaction boundaries, or why those are more sacred than other kinds of project history. There's no clear explanation of why "project history" should be immutable, or even what constitutes "project history" exactly. It sounds generally like a good idea to keep history to me, heck I'm on board! But the reasons to be absolute about it have not at all been clearly established, only stated dogmatically.
Everyone jumping on me is defending the use of the words "dishonest", "fabricate", "white-wash", "lying", and "deceive" as though they're merely accurate and not what they are: intentional attempts to induce shame about rebase. My point is, simply, that this is spin and it's misplaced because git was not designed to take away your freedom to modify your commit history.
I once ordered a cheeseburger and got a “burger” without a beef patty or any other kind of meat, not even the veggie pretend meat. Just bread, sauce, pickles and a single slice of cheese.
I felt pretty disappointed with that “cheeseburger”.
Anyway, my point is that the real world lying about cheeseburgers situation is a lot worse than pulling a fast one and handing over a chicken sandwich.
I would begrudgingly have accepted a chicken sandwich.
It is a little better, and I’d like to acknowledge that you were open to the idea and thank you for taking action.
I haven’t been entirely persuasive here, so I’m reflecting on how to better elaborate my thoughts. The singular word “lying” isn’t really the main thrust of my objection.
Maybe the biggest issue I see still there is the assertions about the intent behind rebase, which means the intent of git’s developers and git rebase users. It’s not really true that rebase intends to “deceive”, that’s not how the authors of the feature talk about it or frame the feature. In my opinion, it’s a semantic cop-out to claim the words are factual and non-judgemental, when the negative thrust of your choice of language is evident, and when there are clearly less loaded words available to you.
It is in that sense - your assertion that the primary intent behind rebase is to deceive people - that I feel like the Fossil documentation is still not being particularly truthful with the facts.
One way to look at this is to ask what would happen if git removed rebase. Right now, if that happened, and git didn’t change anything else about it’s design, it would be somewhat frustrating and unusable. Rebase doesn’t exist on an island, and removing it would have negative consequences, and need to be replaced with other features. Git doesn’t have a way to present a clean history without rebase there. It would be awesome for Fossil’s story to note how the fundamental design is an improvement over git.
I know your framing and language is intentional because you believe strongly in the idea of preserving project history. That is an acceptable, even laudable goal. I’m for it. Git did not have that goal when it was designed, and it’s not fair to selectively leave out that fact when criticizing. Aren’t there better ways to make the point without presuming to proclaim what the intent of rebase is? Can’t the harmful implications of rebase be demonstrated rather than framing it as “fictitious”, “fabricated”, “counter-factual”? Could you talk about it without accusing innocent bystanders of “white-washing” and being “untruthful”?
BTW, I think the Pro Git book commentary isn’t that fair to hold up as evidence for two reasons - they didn’t design rebase, and they are also trying to softly address the very argument you’re putting forward, because it keeps coming around. The existence of their comments doesn’t somehow prove that git designed rebase to “lie”, it only shows that they heard you.
Can you see, though, how using rebase to "clean" the historical record—irrespective of your intentions—is in fact deceiving the reader by presenting a narrative that is in fact different to the actual events that took place? If so, please provide a better way to convey this message than how it is currently being stated. If you can't see the deception—motive notwithstanding—then we're at an impasse.
> 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.
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.
That looks to be someone presenting their opinion—not a statement of fact. Ironically, too, considering the guidelines they link guides users to not do what they're doing.
Welcome to Hacker News. Since you’re new here, you seem to be unaware of the fact that the person who’s opinion you’re referring to and attempting to dismiss is one of the moderators of HN, and one of the authors and keepers of this site’s guidelines.
It’s not uncommon to bump into this claim in threads about git, I don’t think the Fossil devs came up with this idea, but they sure are running with it. This is an argument whose time has passed and needs to die. It’s not helpful.
Please @Fossil devs, come up with better and more honest reasons to compare Fossil to git. If I don’t have to rebase again, that’s great! If Fossil avoids merge conflicts more often, and handles merge conflicts better, absolutely fantastic.
But, please, come on. Rebase is “lying” exactly just as much as hitting backspace is “lying”. Am I lying if I fix a typo or a bug before I commit? Do you really want to preserve all keystrokes ever typed on your keyboard during development? Does Fossil actually capture all keystrokes? If not, then are you sure Fossil is not lying about development history by your definition? Being able to clean and organize your development history before you share it with others is an intentional feature, not a bug. Attempting to claim a moral high ground over what is purely a technical and workflow issue is making Fossil look ignorant to me, it’s doing the opposite of what you want.