6 ms·

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

by dahart 6y ago

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.

SQLite 6y ago
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.
- taberiand 6y ago
  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.
- harryvederci 6y ago
  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.
  - dahart 6y ago
    Well said. Exactly. I agree 100%. > I never understood why people want to change commit history in Git FWIW, by and large, they don’t, not after it’s been pushed. That’s one of the major problems with this critique.
  - bachmeier 6y ago
    > 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.

by dahart 6y ago

SQLite 6y ago

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.

taberiand 6y ago
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.
harryvederci 6y ago
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.
- dahart 6y ago
  Well said. Exactly. I agree 100%. > I never understood why people want to change commit history in Git FWIW, by and large, they don’t, not after it’s been pushed. That’s one of the major problems with this critique.
- bachmeier 6y ago
  > 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.