3 ms·

> I’m surprised that’s the #1 magic-wand project for anyone. It seems like Dr. Hipp is frustrated that Fossil hasn’t had mainstream adoption, and that git has,

by dahart 4y ago

> I’m surprised that’s the #1 magic-wand project for anyone. It seems like Dr. Hipp is frustrated that Fossil hasn’t had mainstream adoption, and that git has, he’s talked about it quite a bit in Fossil docs and here on HN. Given that SQLite is very stable and adoption is an absolutely runaway success, I’m not too surprised his wish list now turns to Fossil. > Fossil’s mental model is, by choice, way different from git. Is that accurate? It does come with a ton of extra features, but seems like the core version control model is quite similar conceptually, and differs more on implementation (SQLite backing instead of file system) and workflow dogma (Fossil’s moralizing of rebase and commit graph edits). The Fossil docs even start with “The feature sets of Fossil and Git overlap in many ways.” Fossil was released after but within a year of git being released, the timeline and docs and comments from the authors generally suggest it’s a reaction to git, taking the good parts and trying to, in the authors’ eyes, improve and fix their perceived problems with git.

mdaniel 4y ago
I don't mean DAG versus "lolol," because I'm not saying Fossil isn't an SCM, I'm pointing out the design choices which presumably someone who wants to use Fossil buys into and thus would be a culture clash with trying to participate with the git upstream. I am cognizant this is quoting a bunch from the same page but pull-quotes the anti-git stance that makes me question whether this is a technical problem We'll start with Fossil not tolerating `git rebase` or `git commit --amend`: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#history https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... and the number of repos I've seen where PRs don't land without someone chirping about "please rebase your branch" "Fossil was designed for [...] just four programmers, and 64% of it is from the lead developer alone. [They] know each other well and interact daily." https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#scale https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... makes one wonder what kind of awesomeness would ensue if running `fit clone https://github.com/chromium/chromium.git https://github.com/chromium/chromium.git` and its related topic: "Fossil is not designed for drive-by contributions" and "Where Git encourages siloed development, Fossil fights against it.": https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#devorg https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... -- I would be really sad to have all my working changes auto-pushed by the tool, although the https://github.com/martinvonz/jj#readme https://github.com/martinvonz/jj#readme is also in that spirit, where almost every operation is a `git add . && git commit -mwip` Fossil is `git push --mirror` by default: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#branches https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... versus `git push origin HEAD` which is what most people think of with "git push" Then, as one of the obvious actual technical issues: Fossil is SHA-3: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#hash https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
- 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.

by dahart 4y ago

mdaniel 4y ago

I don't mean DAG versus "lolol," because I'm not saying Fossil isn't an SCM, I'm pointing out the design choices which presumably someone who wants to use Fossil buys into and thus would be a culture clash with trying to participate with the git upstream. I am cognizant this is quoting a bunch from the same page but pull-quotes the anti-git stance that makes me question whether this is a technical problem We'll start with Fossil not tolerating `git rebase` or `git commit --amend`: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#history https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... and the number of repos I've seen where PRs don't land without someone chirping about "please rebase your branch" "Fossil was designed for [...] just four programmers, and 64% of it is from the lead developer alone. [They] know each other well and interact daily." https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#scale https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... makes one wonder what kind of awesomeness would ensue if running `fit clone https://github.com/chromium/chromium.git https://github.com/chromium/chromium.git` and its related topic: "Fossil is not designed for drive-by contributions" and "Where Git encourages siloed development, Fossil fights against it.": https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#devorg https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... -- I would be really sad to have all my working changes auto-pushed by the tool, although the https://github.com/martinvonz/jj#readme https://github.com/martinvonz/jj#readme is also in that spirit, where almost every operation is a `git add . && git commit -mwip` Fossil is `git push --mirror` by default: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#branches https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w... versus `git push origin HEAD` which is what most people think of with "git push" Then, as one of the obvious actual technical issues: Fossil is SHA-3: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#hash https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...

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.