16 ms·

Fossil versus Git

97 points by susam 3y ago

helloguillecl 3y ago
I love git and I find no reason to look for anything else. Most of the complains I hear from git is from people that could not learn its logic. I think a lot of things could be built on top of git.
- swagonomixxx 3y ago
  Agreed. Over 10 years of development using Git and I perhaps ran into an issue like 10 times, which is once a year on average. I can't think of any other tool that hasn't given me headaches at least once a day. Git is actually remarkable tech and its unfortunate that the prevailing hivemind opinion is that its bad.
  - prepend 3y ago
    > prevailing hivemind opinion is that its bad. I don’t think that’s true. I think the hive mind is that it’s good, or many “haha sucks but I use it all the time.” I work sort of near “data science” and there’s lots of no code/low code people wanting to do data science (or at least bill for it). And I’d say the hive mind in non-coders is that fit is bad. But I think that’s more related to all coding is bad and git is like step 1 to coding so it’s the first hard step they hit.
- pasc1878 3y ago
  Part of fossils's reasoning is that they *DO* understand git's logic but they disagree with it. See most of the points labelled with links to 2.5 plus the comment about showing what you actually did I no rewriting and lying about history, tyhe errors you made are often just as important as the correct way of doing things.
dognotdog 3y ago
I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab. Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of not getting it to work, I just thought screw it, I'll drop everything into fossil, and that was it. I have my issue tracker and wiki and everything, though admittedly I'll have some friction later on if I want to share this project. Not having to deal with random git-lfs errors later on when trying to merge commits with these large files is a plus, and if I ever want to, I can fast-export the repo and ingest it into git.
- prepend 3y ago
  It is extremely rare that I have a file over 100MB. I also think it’s one of those situations where if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better. It’s like in the olden days when you couldn’t put blobs directly in a row so databases made you do your file management yourself instead of just plopping in files. I like git. I don’t like giant binary files in my commit history. It’s cool that you like fossil, but I don’t see this as a reason for me to use it.
  - dwpdwpdwpdwpdwp 3y ago
    Source control is all about managing diffs. Large files are fine, binary doesn’t make sense. Most of the time binary file diffs aren’t human readable. I store binary files outside of git but keep build logs containing binary file CRCs on git
    - tom_ 3y ago
      Most binary files that people want to store in a VCS are stuff like .psd, .xlsx, .docx, and the like - data that's created by people by hand, but not stored as text.
      - prepend 3y ago
        Xlsx and docx are just zipped up xml text. You can store it as text if you like and I think there are many git modules to handle this. But the xml isn’t really that diffable so I don’t bother.
    - masklinn 3y ago
      > Source control is all about managing diffs. Large files are fine, binary doesn’t make sense In git, diffs are literally just a UI thing.
      - wavemode 3y ago
        That's not really true, is it? Surely Git does have an internal concept of diffing changes, specifically so it knows whether two commits can be merged automatically or if they conflict (because they changed the same lines in the same file).
bradley13 3y ago
I don't know Fossil. However, the first entry in the comparison table puts me off. "VCS, tickets, wiki, docs, notes, forum, chat, UI, RBAC" I don't want my version control system to be a wiki. Or a chat app, or any of that.
- toenail 3y ago
  It's a good list actually, and shows what fossil devs value. Which is more often than not something I don't value highly.
- rakoo 3y ago
  That's the thing, fossil isn't merely a VCS, it's a full dev collaboration environment and includes all that is needed
- maegul 3y ago
  Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box. I’ve not used fossil, but I appreciate this idea. Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though these are crazy advanced or complex features.
  - deleted 3y ago
    [deleted]
  - otabdeveloper4 3y ago
    Gitea is already "GitHub in a box". Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting.
    - Zababa 3y ago
      > Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting. What do you mean by this? Having mostly used git and github, I don't really know what I'm missing.
wirrbel 3y ago
I once tried it and ended up losing the history for some weird reason. Maybe its a fixed bug by now, but if I don't want to use git, I will use mercurial.
- rewmie 3y ago
  It's also hard to go through the trouble of onboarding onto a VCS other than Git given a) how ubiquitous it is even and specially in free hosting services, b) Git alternatives don't offer any compelling feature other than contrarian bragging rights for not using Git.
  - wirrbel 3y ago
    > b) Git alternatives don't offer any compelling feature other than contrarian bragging rights for not using Git. oh boy
- probably_wrong 3y ago
  I lost all of my changes the first time I used git, which was the same time I found the error "cannot merge because you have unmerged files" (cut to me yelling "I know, that's why I want to merge!"). I have not yet forgiven git for that, but I'll reluctantly accept that me not knowing how to use the tool is not entirely the tool's fault. Also: I stand 100% by your alternative solution because Mercurial rocks.
  - thfuran 3y ago
    I'm sad that mercurial lost the vcs war.
  - otp209 3y ago
    >but I'll reluctantly accept that me not knowing how to use the tool is not entirely the tool's fault I don't buy this. A good tool should do its job and stay out of your way. The amount of pointless knowledge I now have just to be able to use a version control system for my job still to this day annoys me. Linus Torvalds isn't some infallible god, and it may be useful for linux kernel development, but we're not all linux kernel developers; and tools like VCSes, when designed well, should be unnoticed until the exact moment you need them, convenient and simple to use, and not get in your way or create problems for you where there weren't any to begin with. (Holy run-on sentences, Batman!) In contrast, git goes out of its way to throw itself in your face at every opportunity, exacerbate your problems, and create a maze you either have to navigate precisely or just decide "fuck it" and do a copy/replace file trick just to get back on track with what you were actually doing. The fact that people keep prescribing "just learn all its intricacies" or other band-aids (like the other "use with" software suggestions here) rather than even acknowledging it as a problem, to me, points to the lack of UX expertise in the field, and to stockholm syndrome. (Which, funnily enough, is a problem things like git contributes to. It being one of the first things required to learn in CS, I constantly wonder how many of my peers might've switched out of the field given the mess it is, assuming CS wasn't for them. And, in turn, the breakthroughs we might've missed out on having earlier.) Tools should be simple and usable, not throw up arbitrary barriers to entry.
mgaunard 3y ago
Stopped reading at first point; why would I want my versioning system coupled to a bunch of random services? Doing one thing and one thing only is a feature, not a bug.
- prepend 3y ago
  Wouldn’t it be great if my car also brewed coffee? I drink coffee every day on the way to work. I’m always in a hurry. It would be convenient to just build that in. I always drink coffee while driving, I may as well just build it in. Cut to a month later because my car won’t start because I’m out of coffee grounds. This is how fossil seems to me. I probably have hundreds of repos with just versioned files. That’s it. I don’t want an issue tracker and chat and everything else in my git. And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever. Comically, I’d probably use the fossil service if it supported git. Anyone else remember when Google Code only supported mercurial? And they talked about how much better mercurial was than git. And they were right. And no one cared. I hope fossil sticks around because I like more services. But if I was interviewing for a company and they said that I must use fossil, I probably wouldn’t work there. (This is similar to if they said you must use TFS or something else weird) I’ve used so many version controls over the years (vss, cvs, subversion, clearcase, perforce, bitkeeper, tfs, mercurial, manual file system hacks) and I need a really good reason to use something other than git. Making it more complex is not a reason I accept.
  - rakoo 3y ago
    > And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever. And not the wiki, the issues, the releases, the forums, the website, and all that stuff that is probably needed once your project starts to involve a few people.
    - prepend 3y ago
      First, those are bolt-ons and I don’t actually want them tied to the source code management system. Second, for my repos, I use markdown directly in the repo instead of a wiki. This works better for me because the version history is in the repo and for wikis the author is important context for the value of the information. Third, I build my website using an ssg that builds off my repo. Typically this is Jekyll scripts that build out fine on GitHub pages or gitlab pages or whatever. And I can move to any host I want. I don’t want to couple my project’s web site to my source code host. These are “solved” features as far as I’m concerned and these actually bring negative value for me. I don’t want to worry about what kind of forum functionality my scm provides. And I certainly don’t care about pushing my forum from one server to another.
nightfader 3y ago
The whole point that git rejects large blobs is primarily because they don't belong in VCS. But for those who need large blobs there is git-lfs as the author mentioned. I don't see a problem with that approach because I personally don't like my git repos growing large after just a few commits which then takes up time for huge clones by other devs. This is the whole principle behind monorepos. If going the monorepo route it's in a teams or projects best interest by keeping the repo size small so new clone by newly onboarded devs or during a CI pipeline don't take forever. Fossil is an all in one VCS with wiki, issues etc which I don't appreciate because for one it's not feature rich and for another it bloats the backups and restores. So I prefer gits Unix philosophy of doing one thing but doing it really well. There are some philosophical amd usability differences between fossil and git too but in the grand scheme of things it doesn't matter when one has been using git for a long time. Fossil doesn't have an ecosystem either and making it work with CI CD is a pain because CD tools like agrocd or flux or CI tools like gitlab/gitbub/circle/travis CI systems don't work with fossil out of the box.
- IshKebab 3y ago
  People only think large blobs don't belong in VCS because they don't work well with Git. As soon as a VCS comes along that actually handles that properly people will say "of course, it was obvious that it should have been like this all along!". Git LFS is a proof of concept, not a real solution. Unfortunately none of the new Git alternatives I've seen (Jujitsu, Pijul etc) are tackling the real pain points of Git: * Submodule support is incomplete, buggy and unintuitive * No way to store large files that actually integrates properly with Git. * Poor support for very large monorepos where you only want to clone part of it. In a way, Git is bad at everything that centralised VCS systems are good at, which isn't surprising given that it's decentralised. The problem is that most people actually use it as a centralised VCS and want those features.
- maccard 3y ago
  > The whole point that git rejects large blobs is primarily because they don't belong in VCS. Who are you to say that my blobs don't belong in version control? Where does a versioned asset file for a website or a game go, if not in version control? If the answer is "somewhere else referneced by the git commit", then you're accepting that the data belongs in version control but that git can't handle it. > But for those who need large blobs there is git-lfs as the author mentioned. git-lfs isn't git, though. It's a bodge on top of git that breaks many of the assumptions about git, requires special handling and setup. If it _were_ a core part of git I would agree, but it's not. > So I prefer gits Unix philosophy of doing one thing but doing it really well Git is tightly coupled to a _bunch_ of unix tools, and doesn't work without them. Try running git on windows and see that installs an entire suite of posix tools (msys) just to let you run `git clone`.
henrydark 3y ago
Lots of people are saying that having large files in a repo is wrong, bad, bad design, incorrect usage. Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that? The major issue with big files is resources: storage, and network bandwidth. But for both of these it is the sum of all object sizes in a repo that matters, not any particular file, so it's weird to be harking on big files being bad design or evil.
- iaresee 3y ago
  I did just over a decade in chip design. Versioning large files in that domain is commonplace and quite sane. It can take wallclock days of processing to produce a layout file that's 100's of MBs. Keeping that asset in your SCC system along side all the block assets it was built up out of is very desireable. Perforce handled it all like a champ. People who think large files don't belong in SCC are...wrong.
  - ChrisMarshallNY 3y ago
    That's why Perforce is still the SCM of choice for a lot of creatives. I don't know if they still do it, but Unreal used to ship a Perforce license with their SDK.
    - nightfader 3y ago
      That's also why perforce is slow as heck unless you throw massive resources at it. I also work in the chip industry BTW.
      - ChrisMarshallNY 3y ago
        I don't like it (but used it for many years). I love Git, but, then, I don't have a workflow that would benefit from Perforce.
      - 3y ago
Supermancho 3y ago
A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that often. The last time I used rebase at a job was maybe 5 years ago? Other than that my bigger gripe is when I read something like this: > Git strives to record what the development of a project should have looked like had there been no mistakes Git does not strive to do this. It allows it, to some degree. This is not the same thing at all and is basically FUD. I would say the debate is ongoing as to the value of history rewriting. It's probably a tradeoff that some orgs are willing to leverage and Fossil is masking that they allow less flexibility in workflows as an obvious advantage, feels slimy.
- bloopernova 3y ago
  Regarding rebase, it's been my experience that among many developers rebase has a mythical status. You're "supposed to" rebase, but no one knows the benefit of doing so. It's a big downside of git being treated like some magical difficult spell. Same with exiting Vim, people treat it as way harder than it really is.
  - bradley13 3y ago
    I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there are a couple of weird commits, who cares? At most, maybe edit the commit messages to explain.
    - Kamq 3y ago
      Usually it's if you committed something you shouldn't have. You still have to change api keys if you ever pushed, because things like github store orphan commits, but if you have something you can't change in there or you catch it before you push, it will at least go away eventually.
    - snuxoll 3y ago
      Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history but also for code review purposes. There’s plenty of reason to use rebase, but if you’re fine letting the occasional mess slip into the history then it’s fine to NOT use it as well. The one universal case though. Rebase before you submit a patchset for review. I don’t want to fight through merge conflicts to review a change, make sure it’s applied to the current HEAD before you send it.
unnouinceput 3y ago
Lacks (2020) in title. This article is written in Feb. 2020.
- SQLite 3y ago
  The document first appeared 2010-11-11. The latest change was on 2023-05-10. See https://www.fossil-scm.org/home/finfo/www/fossil-v-git.wiki https://www.fossil-scm.org/home/finfo/www/fossil-v-git.wiki for a complete change history for the document - including changes on branches. Aside: How would you get this information (the complete change history in a single file of a larger project) if the repository was on GitHub? Helpful hint: Click two nodes on the graph to see a diff between the two selected versions.
  - unnouinceput 3y ago
    Personally I read the article. It has, in the last chapter, the following: " As of this writing in February 2020...", so yeah, written by the author.
visarga 3y ago
Wow, small fonts on full screen width. That's why screen readers were invented though.
- remram 3y ago
  That's definitely not why. Maybe you mean "reader view"?
diego_moita 3y ago
My problem with Fossil is that it is a "one solution for all problems". Fossil packs all solutions together while the Git ecosystem provides several different solutions for each problem. When you want to do things that Fossil is not meant to do, then you're in trouble. I have no idea on how to do CI/CD and DevOps with Fossil and how to integrate it with AWS/Azure/GCP. I find the whole ecosystem of Gitlab/Github, Notion, Jira and stand-alone alternatives like Gitea [1], Gogs [2], Gitprep[3] and others to be more flexible and versatile. [1] https://about.gitea.com/ https://about.gitea.com/ [2] https://gogs.io/ https://gogs.io/ [3] https://github.com/yuki-kimoto/gitprep https://github.com/yuki-kimoto/gitprep
idiot900 3y ago
If Fossil is so against deleting commits, what do you do if you've accidentally committed sensitive information that cannot live in any form in the repo?
- mdgrech23 3y ago
  That's a good point. Delete the repo and start over I suppose? W/ git wouldn't it possible to find and restore that info anyway? Guess it becomes what do you care about most at that point.
- maccard 3y ago
  I'm not a fossil user but https://fossil-scm.org/home/help/purge https://fossil-scm.org/home/help/purge
  - mkl 3y ago
    And yet: > FURTHER WARNING: This command is a work-in-progress and may yet contain bugs.
    - sgbeal 3y ago
      > FURTHER WARNING: This command is a work-in-progress and may yet contain bugs. Purging and shunning are two entirely different things in fossil. Shunning is for removing "bad" content and purging is very specifically for use with the "bundle" command (a rarely-used option for submitting "drive-by patches" initially conceived as fossil's counterpart to pull-requests).
- GuB-42 3y ago
  It is a problem in all decentralized systems. Once you publish something, there is no going back. Anyone of your peers can decide to leave with your sensitive data. That's also what make them so resistant to data loss. Now if you know everyone who has a copy of your repository, you can have them run a bunch of sqlite commands / low level git commands to make sure that the commit is gone. If you didn't publish anything, as someone else said, your best bet is to make an entirely new clone, transfer the work you did on the original, omitting the sensitive data, then nuke the original. The difference seems to be that commits are serious business on fossil, and they encourage you to test before you commit. While on git, commits are more trivial, pushing is where things become serious.
jsnell 3y ago
(2010) Previous discussions: https://news.ycombinator.com/item?id=2524422 https://news.ycombinator.com/item?id=2524422 (86 comments) https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=19006036 (247 comments) https://news.ycombinator.com/item?id=27736980 https://news.ycombinator.com/item?id=27736980 (127 comments) https://news.ycombinator.com/item?id=31696940 https://news.ycombinator.com/item?id=31696940 (73 comments)
RakutenSatori 3y ago
Didn't know about fossil. It's unfortunate many people are saying they stopped reading at the "fossil is everything into one" part because It still looks an interesting way of doing vcs. > 95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model. They propose it as a way to do development with few members who all know each other, rather than making an open repository for anyone on the Internet to contribute. I want to try it now and see what does it bring on the table and whether it's a viable alternative to git in this regard.
- fmajid 3y ago
  I haven’t used Fossil but I have used gittrac, cvstrac in git mode. Cvstrac was what SQLite used before fossil, basically wiki and issue tracker built on top of SQLite, just add CVS, SVN or Git. A very small system compared to Gitea or other forges, but incredibly powerful thanks to SQL and very productive. Fossil is just the logical continuation and shares the same clarity of design and elegant implementation of SQLite.
  - RakutenSatori 3y ago
    Can fossil be better than git for a solo personal project or does it add too much stuff on top that's useful once you have a few people working together and it's much simpler to just git commit?
    - fmajid 3y ago
      I suspect it will work better, but you have to convince all the other collaborators to also switch, as well as lose tooling in say, Xcode.
- deleted 3y ago
  [deleted]
QuadrupleA 3y ago
Been using fossil for several years on my solo projects and loving it. Hoping to see it get wider adoption.
- otp209 3y ago
  Cheers, I'll check it out!
cmrdporcupine 3y ago
Unfortunately for git alternatives, the momentum behind git is in large part pushed by the "social network" aspect of GitHub. In the past I used Mercurial, among other things, for my open source work. And various issue trackers of my own choosing. I am not particularly wedded to Git. But I keep getting sucked into GitHub these days. To get publicity or outside contributions it's hard to avoid the GitHub trap. It's become a discovery service for open source (like Freshmeat.net back in the day), a common reference point for how to do code reviews ("merge requests") and issue tracking (even though it doesn't really do either all that awesomely), but most importantly it's become a place where people network generally. I don't love that this is the case but it's hard to avoid.
- otp209 3y ago
  > Unfortunately for git alternatives, the momentum behind git is in large part pushed by the "social network" aspect of GitHub And there was a time everyone thought facebook wouldn't dethrone myspace, [something.js] wouldn't replace [somethingelse.js], and so on. First mover doesn't mean a lot in software. The network effect you brought up does, but there'll be plenty of people who don't want to get caught up in that "trap" and git/MS-land to seed a decent alternative. (Why should your code discovery networking site be prescribing your choice in VCS, anyway?)
  - cmrdporcupine 3y ago
    I agree with all of this, for sure, and I look forward to the situation changing. And I hope when it does, it does so in a way where the system has more than just Git as an SCM option. I had hopes for bitbucket for a while, but it stagnated, and then Atlassian got their mitts on it.
otp209 3y ago
Git is an absolutely abysmal industry standard and as far as I'm concerned is further proof of my theory that tech is lacking (and actively discourages) much-needed creatives from the field. With them having more representation we would have replaced it years ago.
- munchler 3y ago
  In what way is git evidence of a lack of creatives? I don’t see the connection.
okaleniuk 3y ago
In case you were wondering, there is a "FossilHub": http://chiselapp.com/ http://chiselapp.com/

97 points by susam 3y ago

I love git and I find no reason to look for anything else. Most of the complains I hear from git is from people that could not learn its logic. I think a lot of things could be built on top of git.

swagonomixxx 3y ago
Agreed. Over 10 years of development using Git and I perhaps ran into an issue like 10 times, which is once a year on average. I can't think of any other tool that hasn't given me headaches at least once a day. Git is actually remarkable tech and its unfortunate that the prevailing hivemind opinion is that its bad.
- prepend 3y ago
  > prevailing hivemind opinion is that its bad. I don’t think that’s true. I think the hive mind is that it’s good, or many “haha sucks but I use it all the time.” I work sort of near “data science” and there’s lots of no code/low code people wanting to do data science (or at least bill for it). And I’d say the hive mind in non-coders is that fit is bad. But I think that’s more related to all coding is bad and git is like step 1 to coding so it’s the first hard step they hit.
pasc1878 3y ago
Part of fossils's reasoning is that they *DO* understand git's logic but they disagree with it. See most of the points labelled with links to 2.5 plus the comment about showing what you actually did I no rewriting and lying about history, tyhe errors you made are often just as important as the correct way of doing things.

dognotdog 3y ago

I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab. Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of not getting it to work, I just thought screw it, I'll drop everything into fossil, and that was it. I have my issue tracker and wiki and everything, though admittedly I'll have some friction later on if I want to share this project. Not having to deal with random git-lfs errors later on when trying to merge commits with these large files is a plus, and if I ever want to, I can fast-export the repo and ingest it into git.

prepend 3y ago
It is extremely rare that I have a file over 100MB. I also think it’s one of those situations where if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better. It’s like in the olden days when you couldn’t put blobs directly in a row so databases made you do your file management yourself instead of just plopping in files. I like git. I don’t like giant binary files in my commit history. It’s cool that you like fossil, but I don’t see this as a reason for me to use it.
- dwpdwpdwpdwpdwp 3y ago
  Source control is all about managing diffs. Large files are fine, binary doesn’t make sense. Most of the time binary file diffs aren’t human readable. I store binary files outside of git but keep build logs containing binary file CRCs on git
  - tom_ 3y ago
    Most binary files that people want to store in a VCS are stuff like .psd, .xlsx, .docx, and the like - data that's created by people by hand, but not stored as text.
    - prepend 3y ago
      Xlsx and docx are just zipped up xml text. You can store it as text if you like and I think there are many git modules to handle this. But the xml isn’t really that diffable so I don’t bother.
  - masklinn 3y ago
    > Source control is all about managing diffs. Large files are fine, binary doesn’t make sense In git, diffs are literally just a UI thing.
    - wavemode 3y ago
      That's not really true, is it? Surely Git does have an internal concept of diffing changes, specifically so it knows whether two commits can be merged automatically or if they conflict (because they changed the same lines in the same file).

bradley13 3y ago

I don't know Fossil. However, the first entry in the comparison table puts me off. "VCS, tickets, wiki, docs, notes, forum, chat, UI, RBAC" I don't want my version control system to be a wiki. Or a chat app, or any of that.

toenail 3y ago
It's a good list actually, and shows what fossil devs value. Which is more often than not something I don't value highly.
rakoo 3y ago
That's the thing, fossil isn't merely a VCS, it's a full dev collaboration environment and includes all that is needed
maegul 3y ago
Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box. I’ve not used fossil, but I appreciate this idea. Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though these are crazy advanced or complex features.
- deleted 3y ago
  [deleted]
- otabdeveloper4 3y ago
  Gitea is already "GitHub in a box". Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting.
  - Zababa 3y ago
    > Also, GitHub is not something to emulate, it is the lowest common denominator of repo hosting. What do you mean by this? Having mostly used git and github, I don't really know what I'm missing.

wirrbel 3y ago

I once tried it and ended up losing the history for some weird reason. Maybe its a fixed bug by now, but if I don't want to use git, I will use mercurial.

rewmie 3y ago
It's also hard to go through the trouble of onboarding onto a VCS other than Git given a) how ubiquitous it is even and specially in free hosting services, b) Git alternatives don't offer any compelling feature other than contrarian bragging rights for not using Git.
- wirrbel 3y ago
  > b) Git alternatives don't offer any compelling feature other than contrarian bragging rights for not using Git. oh boy
probably_wrong 3y ago
I lost all of my changes the first time I used git, which was the same time I found the error "cannot merge because you have unmerged files" (cut to me yelling "I know, that's why I want to merge!"). I have not yet forgiven git for that, but I'll reluctantly accept that me not knowing how to use the tool is not entirely the tool's fault. Also: I stand 100% by your alternative solution because Mercurial rocks.
- thfuran 3y ago
  I'm sad that mercurial lost the vcs war.
- otp209 3y ago
  >but I'll reluctantly accept that me not knowing how to use the tool is not entirely the tool's fault I don't buy this. A good tool should do its job and stay out of your way. The amount of pointless knowledge I now have just to be able to use a version control system for my job still to this day annoys me. Linus Torvalds isn't some infallible god, and it may be useful for linux kernel development, but we're not all linux kernel developers; and tools like VCSes, when designed well, should be unnoticed until the exact moment you need them, convenient and simple to use, and not get in your way or create problems for you where there weren't any to begin with. (Holy run-on sentences, Batman!) In contrast, git goes out of its way to throw itself in your face at every opportunity, exacerbate your problems, and create a maze you either have to navigate precisely or just decide "fuck it" and do a copy/replace file trick just to get back on track with what you were actually doing. The fact that people keep prescribing "just learn all its intricacies" or other band-aids (like the other "use with" software suggestions here) rather than even acknowledging it as a problem, to me, points to the lack of UX expertise in the field, and to stockholm syndrome. (Which, funnily enough, is a problem things like git contributes to. It being one of the first things required to learn in CS, I constantly wonder how many of my peers might've switched out of the field given the mess it is, assuming CS wasn't for them. And, in turn, the breakthroughs we might've missed out on having earlier.) Tools should be simple and usable, not throw up arbitrary barriers to entry.

mgaunard 3y ago

Stopped reading at first point; why would I want my versioning system coupled to a bunch of random services? Doing one thing and one thing only is a feature, not a bug.

prepend 3y ago
Wouldn’t it be great if my car also brewed coffee? I drink coffee every day on the way to work. I’m always in a hurry. It would be convenient to just build that in. I always drink coffee while driving, I may as well just build it in. Cut to a month later because my car won’t start because I’m out of coffee grounds. This is how fossil seems to me. I probably have hundreds of repos with just versioned files. That’s it. I don’t want an issue tracker and chat and everything else in my git. And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever. Comically, I’d probably use the fossil service if it supported git. Anyone else remember when Google Code only supported mercurial? And they talked about how much better mercurial was than git. And they were right. And no one cared. I hope fossil sticks around because I like more services. But if I was interviewing for a company and they said that I must use fossil, I probably wouldn’t work there. (This is similar to if they said you must use TFS or something else weird) I’ve used so many version controls over the years (vss, cvs, subversion, clearcase, perforce, bitkeeper, tfs, mercurial, manual file system hacks) and I need a really good reason to use something other than git. Making it more complex is not a reason I accept.
- rakoo 3y ago
  > And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever. And not the wiki, the issues, the releases, the forums, the website, and all that stuff that is probably needed once your project starts to involve a few people.
  - prepend 3y ago
    First, those are bolt-ons and I don’t actually want them tied to the source code management system. Second, for my repos, I use markdown directly in the repo instead of a wiki. This works better for me because the version history is in the repo and for wikis the author is important context for the value of the information. Third, I build my website using an ssg that builds off my repo. Typically this is Jekyll scripts that build out fine on GitHub pages or gitlab pages or whatever. And I can move to any host I want. I don’t want to couple my project’s web site to my source code host. These are “solved” features as far as I’m concerned and these actually bring negative value for me. I don’t want to worry about what kind of forum functionality my scm provides. And I certainly don’t care about pushing my forum from one server to another.

nightfader 3y ago

The whole point that git rejects large blobs is primarily because they don't belong in VCS. But for those who need large blobs there is git-lfs as the author mentioned. I don't see a problem with that approach because I personally don't like my git repos growing large after just a few commits which then takes up time for huge clones by other devs. This is the whole principle behind monorepos. If going the monorepo route it's in a teams or projects best interest by keeping the repo size small so new clone by newly onboarded devs or during a CI pipeline don't take forever. Fossil is an all in one VCS with wiki, issues etc which I don't appreciate because for one it's not feature rich and for another it bloats the backups and restores. So I prefer gits Unix philosophy of doing one thing but doing it really well. There are some philosophical amd usability differences between fossil and git too but in the grand scheme of things it doesn't matter when one has been using git for a long time. Fossil doesn't have an ecosystem either and making it work with CI CD is a pain because CD tools like agrocd or flux or CI tools like gitlab/gitbub/circle/travis CI systems don't work with fossil out of the box.

IshKebab 3y ago
People only think large blobs don't belong in VCS because they don't work well with Git. As soon as a VCS comes along that actually handles that properly people will say "of course, it was obvious that it should have been like this all along!". Git LFS is a proof of concept, not a real solution. Unfortunately none of the new Git alternatives I've seen (Jujitsu, Pijul etc) are tackling the real pain points of Git: * Submodule support is incomplete, buggy and unintuitive * No way to store large files that actually integrates properly with Git. * Poor support for very large monorepos where you only want to clone part of it. In a way, Git is bad at everything that centralised VCS systems are good at, which isn't surprising given that it's decentralised. The problem is that most people actually use it as a centralised VCS and want those features.
maccard 3y ago
> The whole point that git rejects large blobs is primarily because they don't belong in VCS. Who are you to say that my blobs don't belong in version control? Where does a versioned asset file for a website or a game go, if not in version control? If the answer is "somewhere else referneced by the git commit", then you're accepting that the data belongs in version control but that git can't handle it. > But for those who need large blobs there is git-lfs as the author mentioned. git-lfs isn't git, though. It's a bodge on top of git that breaks many of the assumptions about git, requires special handling and setup. If it _were_ a core part of git I would agree, but it's not. > So I prefer gits Unix philosophy of doing one thing but doing it really well Git is tightly coupled to a _bunch_ of unix tools, and doesn't work without them. Try running git on windows and see that installs an entire suite of posix tools (msys) just to let you run `git clone`.

henrydark 3y ago

Lots of people are saying that having large files in a repo is wrong, bad, bad design, incorrect usage. Forget that you know git, github, git-lfs, even software engineering for a moment. All you know is that you're developing a general project on a computer, you are using files, and you want version history on everything. What's wrong with that? The major issue with big files is resources: storage, and network bandwidth. But for both of these it is the sum of all object sizes in a repo that matters, not any particular file, so it's weird to be harking on big files being bad design or evil.

iaresee 3y ago
I did just over a decade in chip design. Versioning large files in that domain is commonplace and quite sane. It can take wallclock days of processing to produce a layout file that's 100's of MBs. Keeping that asset in your SCC system along side all the block assets it was built up out of is very desireable. Perforce handled it all like a champ. People who think large files don't belong in SCC are...wrong.
- ChrisMarshallNY 3y ago
  That's why Perforce is still the SCM of choice for a lot of creatives. I don't know if they still do it, but Unreal used to ship a Perforce license with their SDK.
  - nightfader 3y ago
    That's also why perforce is slow as heck unless you throw massive resources at it. I also work in the chip industry BTW.
    - ChrisMarshallNY 3y ago
      I don't like it (but used it for many years). I love Git, but, then, I don't have a workflow that would benefit from Perforce.
    - 3y ago

Supermancho 3y ago

A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that often. The last time I used rebase at a job was maybe 5 years ago? Other than that my bigger gripe is when I read something like this: > Git strives to record what the development of a project should have looked like had there been no mistakes Git does not strive to do this. It allows it, to some degree. This is not the same thing at all and is basically FUD. I would say the debate is ongoing as to the value of history rewriting. It's probably a tradeoff that some orgs are willing to leverage and Fossil is masking that they allow less flexibility in workflows as an obvious advantage, feels slimy.

bloopernova 3y ago
Regarding rebase, it's been my experience that among many developers rebase has a mythical status. You're "supposed to" rebase, but no one knows the benefit of doing so. It's a big downside of git being treated like some magical difficult spell. Same with exiting Vim, people treat it as way harder than it really is.
- bradley13 3y ago
  I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there are a couple of weird commits, who cares? At most, maybe edit the commit messages to explain.
  - Kamq 3y ago
    Usually it's if you committed something you shouldn't have. You still have to change api keys if you ever pushed, because things like github store orphan commits, but if you have something you can't change in there or you catch it before you push, it will at least go away eventually.
  - snuxoll 3y ago
    Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history but also for code review purposes. There’s plenty of reason to use rebase, but if you’re fine letting the occasional mess slip into the history then it’s fine to NOT use it as well. The one universal case though. Rebase before you submit a patchset for review. I don’t want to fight through merge conflicts to review a change, make sure it’s applied to the current HEAD before you send it.

unnouinceput 3y ago

Lacks (2020) in title. This article is written in Feb. 2020.

SQLite 3y ago
The document first appeared 2010-11-11. The latest change was on 2023-05-10. See https://www.fossil-scm.org/home/finfo/www/fossil-v-git.wiki https://www.fossil-scm.org/home/finfo/www/fossil-v-git.wiki for a complete change history for the document - including changes on branches. Aside: How would you get this information (the complete change history in a single file of a larger project) if the repository was on GitHub? Helpful hint: Click two nodes on the graph to see a diff between the two selected versions.
- unnouinceput 3y ago
  Personally I read the article. It has, in the last chapter, the following: " As of this writing in February 2020...", so yeah, written by the author.

visarga 3y ago

Wow, small fonts on full screen width. That's why screen readers were invented though.

remram 3y ago
That's definitely not why. Maybe you mean "reader view"?

diego_moita 3y ago

My problem with Fossil is that it is a "one solution for all problems". Fossil packs all solutions together while the Git ecosystem provides several different solutions for each problem. When you want to do things that Fossil is not meant to do, then you're in trouble. I have no idea on how to do CI/CD and DevOps with Fossil and how to integrate it with AWS/Azure/GCP. I find the whole ecosystem of Gitlab/Github, Notion, Jira and stand-alone alternatives like Gitea [1], Gogs [2], Gitprep[3] and others to be more flexible and versatile. [1] https://about.gitea.com/ https://about.gitea.com/ [2] https://gogs.io/ https://gogs.io/ [3] https://github.com/yuki-kimoto/gitprep https://github.com/yuki-kimoto/gitprep

idiot900 3y ago

If Fossil is so against deleting commits, what do you do if you've accidentally committed sensitive information that cannot live in any form in the repo?

mdgrech23 3y ago
That's a good point. Delete the repo and start over I suppose? W/ git wouldn't it possible to find and restore that info anyway? Guess it becomes what do you care about most at that point.
maccard 3y ago
I'm not a fossil user but https://fossil-scm.org/home/help/purge https://fossil-scm.org/home/help/purge
- mkl 3y ago
  And yet: > FURTHER WARNING: This command is a work-in-progress and may yet contain bugs.
  - sgbeal 3y ago
    > FURTHER WARNING: This command is a work-in-progress and may yet contain bugs. Purging and shunning are two entirely different things in fossil. Shunning is for removing "bad" content and purging is very specifically for use with the "bundle" command (a rarely-used option for submitting "drive-by patches" initially conceived as fossil's counterpart to pull-requests).
GuB-42 3y ago
It is a problem in all decentralized systems. Once you publish something, there is no going back. Anyone of your peers can decide to leave with your sensitive data. That's also what make them so resistant to data loss. Now if you know everyone who has a copy of your repository, you can have them run a bunch of sqlite commands / low level git commands to make sure that the commit is gone. If you didn't publish anything, as someone else said, your best bet is to make an entirely new clone, transfer the work you did on the original, omitting the sensitive data, then nuke the original. The difference seems to be that commits are serious business on fossil, and they encourage you to test before you commit. While on git, commits are more trivial, pushing is where things become serious.

jsnell 3y ago

(2010) Previous discussions: https://news.ycombinator.com/item?id=2524422 https://news.ycombinator.com/item?id=2524422 (86 comments) https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=19006036 (247 comments) https://news.ycombinator.com/item?id=27736980 https://news.ycombinator.com/item?id=27736980 (127 comments) https://news.ycombinator.com/item?id=31696940 https://news.ycombinator.com/item?id=31696940 (73 comments)

RakutenSatori 3y ago

Didn't know about fossil. It's unfortunate many people are saying they stopped reading at the "fossil is everything into one" part because It still looks an interesting way of doing vcs. > 95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model. They propose it as a way to do development with few members who all know each other, rather than making an open repository for anyone on the Internet to contribute. I want to try it now and see what does it bring on the table and whether it's a viable alternative to git in this regard.

fmajid 3y ago
I haven’t used Fossil but I have used gittrac, cvstrac in git mode. Cvstrac was what SQLite used before fossil, basically wiki and issue tracker built on top of SQLite, just add CVS, SVN or Git. A very small system compared to Gitea or other forges, but incredibly powerful thanks to SQL and very productive. Fossil is just the logical continuation and shares the same clarity of design and elegant implementation of SQLite.
- RakutenSatori 3y ago
  Can fossil be better than git for a solo personal project or does it add too much stuff on top that's useful once you have a few people working together and it's much simpler to just git commit?
  - fmajid 3y ago
    I suspect it will work better, but you have to convince all the other collaborators to also switch, as well as lose tooling in say, Xcode.
deleted 3y ago
[deleted]

QuadrupleA 3y ago

Been using fossil for several years on my solo projects and loving it. Hoping to see it get wider adoption.

otp209 3y ago
Cheers, I'll check it out!

cmrdporcupine 3y ago

Unfortunately for git alternatives, the momentum behind git is in large part pushed by the "social network" aspect of GitHub. In the past I used Mercurial, among other things, for my open source work. And various issue trackers of my own choosing. I am not particularly wedded to Git. But I keep getting sucked into GitHub these days. To get publicity or outside contributions it's hard to avoid the GitHub trap. It's become a discovery service for open source (like Freshmeat.net back in the day), a common reference point for how to do code reviews ("merge requests") and issue tracking (even though it doesn't really do either all that awesomely), but most importantly it's become a place where people network generally. I don't love that this is the case but it's hard to avoid.

otp209 3y ago
> Unfortunately for git alternatives, the momentum behind git is in large part pushed by the "social network" aspect of GitHub And there was a time everyone thought facebook wouldn't dethrone myspace, [something.js] wouldn't replace [somethingelse.js], and so on. First mover doesn't mean a lot in software. The network effect you brought up does, but there'll be plenty of people who don't want to get caught up in that "trap" and git/MS-land to seed a decent alternative. (Why should your code discovery networking site be prescribing your choice in VCS, anyway?)
- cmrdporcupine 3y ago
  I agree with all of this, for sure, and I look forward to the situation changing. And I hope when it does, it does so in a way where the system has more than just Git as an SCM option. I had hopes for bitbucket for a while, but it stagnated, and then Atlassian got their mitts on it.

otp209 3y ago

Git is an absolutely abysmal industry standard and as far as I'm concerned is further proof of my theory that tech is lacking (and actively discourages) much-needed creatives from the field. With them having more representation we would have replaced it years ago.

munchler 3y ago
In what way is git evidence of a lack of creatives? I don’t see the connection.

okaleniuk 3y ago

In case you were wondering, there is a "FossilHub": http://chiselapp.com/ http://chiselapp.com/