3 ms·

Yeah I agree, this isn’t a technical problem. The stated goal is to build the Fossil interface using the git engine, so it’s not Fossil, it’s just an implementa

by dahart 4y ago

Yeah I agree, this isn’t a technical problem. The stated goal is to build the Fossil interface using the git engine, so it’s not Fossil, it’s just an implementation of git that is compatible with Fossil’s workflow. It seems like the assumption there is maybe people want Fossil’s workflow but are stuck having to use git because it’s entrenched. BTW, Fossil’s comparisons to git (especially rebase and rewriting) have always been hyperbolic. It’s improving slowly over the years, however the fundamental problem is still there: the Fossil team is presumptuously stating git’s intentions under Fossil’s overtly moral framework. Git devs have never stated any intention “to record what the development of a project should have looked like had there been no mistakes.” That’s the Fossil team framing things to sell the idea behind Fossil. Ironically, the Fossil team is attempting to rewrite the history of git development by using such language. I think the reason behind Fossil’s lack of adoption isn’t because git is entrenched, I suspect it’s because very few people care about having the ability to record in stone every single commit no matter how messy, most people enjoy having the ability to clean up after the fact. (Not to mention that the idea of capturing and preserving an exact “history” is misguided and fundamentally impossible; it’s already up to me what I put in a commit in the first place, and Fossil is providing dis-incentives to commit early and often, undermining the safety reasons to have version control in the first place.)

robertlagrant 4y ago
The counterpoint is that Git's enables multiple workflows, especially branching and merging, rather than just trunk-based development. Not to say you can't do the latter in Git, but people might struggle to adapt. I think trunk-based, warts and all, is probably the best method for a team that isn't extremely async. Which, I think, makes it useful for a large number of projects.
CRConrad 4y ago
> 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.

by dahart 4y ago

robertlagrant 4y ago

The counterpoint is that Git's enables multiple workflows, especially branching and merging, rather than just trunk-based development. Not to say you can't do the latter in Git, but people might struggle to adapt. I think trunk-based, warts and all, is probably the best method for a team that isn't extremely async. Which, I think, makes it useful for a large number of projects.

CRConrad 4y ago

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