3 ms·

> Git devs have never stated any intention “to record what the development of a project should have looked like had there been no mistakes.” Is that quote talk

> Git devs have never stated any intention “to record what the development of a project should have looked like had there been no mistakes.” Is that quote talking about the development of git, the VCS itself, or about what people use git for; are your "Git devs" the people who develop git, or those who use it to develop other software? As I understand it, some git workflows (that is, workflows using git) are heavy into rewriting history and eliminating branches (or never starting them in the first place) and stuff, but the developers of git never foresaw or mandated that. So my own answer to my question above would be ~"The statement is about both: The developers of git never said that you must use git to straighten out and prettify the history "of a project." Am I reading you correctly in that this is what you too are saying? Because if you are, then I agree: Sounds like Dr Hipp is exaggerating a little, trying to imply that one particular kind of workflow were (almost) mandatory in git. Creates a bit of a strawman, because that kind of workflow is easier to argue against than arguing against a product that allows that kind of workflow and other kinds.

dahart 4y ago
I can’t speak for exactly what the Fossil team meant with that quote, but I guess I don’t think it matters, because the quote isn’t fully in good faith no matter how you take it. I mean it’s no worse than a TV commercial where they make problems look worse than they are to trash the competitor’s product, but it’s no better either. You read my intention correctly, I mean that the developers of git are not enforcing a workflow wrt history (unlike the developers of Fossil). The language on Fossil’s git comparison page use to be worse, it use to say “Rebase is a Lie”, and it used to talk about how people who rewrite history are “fabricating” and “lying”. I actually had a direct conversation with Dr. Hipp here on HN where he agree to soften the language a bit, and he did, which I respect… he is listening. He does, however, believe strongly in the idea that commit history should not be allowed to be ‘rewritten’, so much so that he considers rewriting to be akin to criminal activity. While I don’t agree with that, I have no qualms whatsoever about a VCS that preserves history. It might actually be a really good idea, as long as it’s practical and can be managed and serves the purposes of version control. My only beef is the hyperbolic comparisons to git, the claims that presume to state git’s intent.

dahart 4y ago

I can’t speak for exactly what the Fossil team meant with that quote, but I guess I don’t think it matters, because the quote isn’t fully in good faith no matter how you take it. I mean it’s no worse than a TV commercial where they make problems look worse than they are to trash the competitor’s product, but it’s no better either. You read my intention correctly, I mean that the developers of git are not enforcing a workflow wrt history (unlike the developers of Fossil). The language on Fossil’s git comparison page use to be worse, it use to say “Rebase is a Lie”, and it used to talk about how people who rewrite history are “fabricating” and “lying”. I actually had a direct conversation with Dr. Hipp here on HN where he agree to soften the language a bit, and he did, which I respect… he is listening. He does, however, believe strongly in the idea that commit history should not be allowed to be ‘rewritten’, so much so that he considers rewriting to be akin to criminal activity. While I don’t agree with that, I have no qualms whatsoever about a VCS that preserves history. It might actually be a really good idea, as long as it’s practical and can be managed and serves the purposes of version control. My only beef is the hyperbolic comparisons to git, the claims that presume to state git’s intent.