5 ms·

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 wo

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
  Off topic: 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.
- dahart 6y ago
  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?
  - bachmeier 6y ago
    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.
    - 6y ago

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
Off topic: 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.
dahart 6y ago
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?
- bachmeier 6y ago
  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.
  - 6y ago