6 ms·

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

by 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.
  - chillfox 6y ago
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 ago
  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.
  - dahart 6y ago
    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.
justin66 6y ago
Thanks for explaining the rationale of that feature (or lack thereof) here. Also for the online Fossil docs, which are great.
jeeeb 6y ago
Huge respect for your work on SQLite. I can’t say I agree with this though. > 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.
- chmaynard 6y ago
  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.
Hendrikto 6y ago
> 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.
SQLite 6y ago
The language in the rebase article [1] has been softened somewhat. [1]: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
- dahart 6y ago
  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.

by SQLite 6y ago

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.
- chillfox 6y ago

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 ago
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.
- dahart 6y ago
  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.

justin66 6y ago

Thanks for explaining the rationale of that feature (or lack thereof) here. Also for the online Fossil docs, which are great.

jeeeb 6y ago

Huge respect for your work on SQLite. I can’t say I agree with this though. > 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.

chmaynard 6y ago
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.

Hendrikto 6y ago

> 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.

SQLite 6y ago

The language in the rebase article [1] has been softened somewhat. [1]: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

dahart 6y ago
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.