10 ms·

> Uses the Fossil user interface but it uses the low-level file format of Git. So that then you can work with Fossil’s interface but push and pull to legacy Git

> Uses the Fossil user interface but it uses the low-level file format of Git. So that then you can work with Fossil’s interface but push and pull to legacy Git users. I'm surprised that's the #1 magic-wand project for anyone. I'm not trying to yuck his yum, but am just surprised. But the larger elephant in the room for any such effort is that Fossil's mental model is, by choice, way different from git. If they just want a new ui that isn't as "git sux," surely a new cli to kid-gloves git would be less work than trying to reinvent a whole new version control system, and that goes 1000x for trying to maintain wire compat with every git server in the world

ilyt 4y ago
I don't think Git wire format changes all that often and old clients work with new servers just fine so I don't think that would be a problem. > But the larger elephant in the room for any such effort is that Fossil's mental model is, by choice, way different from git. How? I've been glancing at docs but I don't see much difference, still a DAG of commits that are named after its hash like almost every other DVCS From onlooker perspective the killer feature seems to be integration with project management tools vs "just" being a VCS
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.)

ilyt 4y ago

I don't think Git wire format changes all that often and old clients work with new servers just fine so I don't think that would be a problem. > But the larger elephant in the room for any such effort is that Fossil's mental model is, by choice, way different from git. How? I've been glancing at docs but I don't see much difference, still a DAG of commits that are named after its hash like almost every other DVCS From onlooker perspective the killer feature seems to be integration with project management tools vs "just" being a VCS

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