1. 53
  1.  

  2. 15

    10+ years ago, I switched to git because I considered it better than Subversion. Nowadays, I use git primarily because it’s very popular. I skimmed the article, and didn’t see anything convincing. There’s too much social cost to switching myself and all the teams I’m a member of to something other than git. It almost doesn’t matter how superior any other solution is from a technical standpoint.

    1. 4

      I believe there is a “rule” or something out there that says that in order for something technologically superior to overtake its more popular competitor, it must be vastly superior. Not sure if fossil is there in that regard.

      1. 20

        Fossil doesn’t just have to be vastly superior to git (not that difficult given git’s very low bar on UI consistency); it has to be vastly superior to “git plus whatever tooling people have added on to make it actually usable” such as magit; and that’s a lot harder.

        1. 4

          Although git’s UI is terrible, it may be difficult to vastly improve upon its performance and reliability, considering others have pointed out that fossil has scaling issues. I do think the idea of fossil is great though, our reliance on proprietary and siloed services for stuff like issue tracking makes me uncomfortable.

        2. 7

          I’d highly recommend this book on the economics of technology and information: https://en.wikipedia.org/wiki/Information_Rules

          Part of the ‘value’ of git is that it’s very widely used, beyond just the functionality of the software itself. Those are network effects.

        3. 1

          I agree. We’ve finally arrived at a standard solution that’s both free and works OK. Next stop: \n line-endings everywhere!

        4. 3

          This article is getting a few things about git wrong. They claim git only supports ‘One check-out per repository’. Heard of git worktree?

          They also claim git is only portable to POSIX, yet it runs fine on Windows with full line-ending support. (They achieve this by including the tools like ls, ssh and cat, thereby not requiring the host OS to be posix)

          They claim Sqlite is a superior storage method, yet it is widely known for getting corrupted (probably the reason they run integrity checks all the time), lacks the ability of multiple entities accessing it at the same time, and almost all its column types are silently converted to strings columns with no type checks.

          1. 5

            I don’t think they got this one wrong:

            They also claim git is only portable to POSIX, yet it runs fine on Windows with full line-ending support. (They achieve this by including the tools like ls, ssh and cat, thereby not requiring the host OS to be posix)

            From the article:

            This is largely why the so-called “Git for Windows” distributions (both first-party and third-party) are actually an MSYS POSIX portability environment bundled with all of the Git stuff, because it would be too painful to port Git natively to Windows. Git is a foreign citizen on Windows, speaking to it only through a translator.

            1. 1

              this was also somewhat true of mac os, if you were working with it’s traditional approach to case insensitivity. As the article notes, this is almost by design. Git was built to facilitate linux development, and it’s not surprising that linux hosting is a prerequisite for that.

          2. 2

            Looks like a slam dunk for a lot of users currently on Git. It’s also written by the competition. Any pro-Git people want to counter any of it?

            1. 18

              I’m not really pro-git but I some of the strawman arguments can be easily countered.

              Fossil is more efficient? Then how comes that git scales better? And git does not scale that well either if you look at what Microsoft had to do to it for 300GB. Describing Gitlab has “a third-party extension to Git wrapping it in many features, making it roughly Fossil-equivalent, though much more resource hungry and hence more costly” is so wrong it’s funny. At least, compare with Gitea.

              The article discusses the design philosophies but never considers Torvalds design criteria like speed.

              Fossil uses the most popular database in the world? You could also say git uses an even more popular one called “file system”.

              Git is POSIX only? Git certainly has more windows users than fossil has users in total.

              Fossil has many check-outs per repository? Git also.

              Fossil remembers what you actually did? Git can do that just as well. Git provides a choice where fossil is opinionated.

              In general, this is a one-sided pro-fossil page. Not surprising given the domain. It tells you a lot about the design philosophy behind fossil and is valuable because of that. It is not an honest comparison though.

              1. 11

                Honestly? I don’t actually care which SCM system I use, as long as it talks to GitHub, because that’s where all my code and all my employer’s code lives.

                Furthermore, I use maybe three or four Git commands 99.9% of the time and I have them memorized (and aliased!), so why would I ever switch?

                People complain about Git’s UI and I wonder what it is they’re doing that I don’t do that makes it such a big deal for them. I’m not saying they’re wrong, but I kind of suspect that most devs are more like me, they treat SCM as a black box utility, like the CPU or the memory, and that’s why we’re moving toward a monoculture, because it just doesn’t matter to most people.

                1. 11

                  Not a pro-Git, but when I considered switching to Fossil there was no (easy) equivalent of git rebase -i.

                  That was probably my biggest complaint.

                  1. 4

                    The article explains that this is a deliberate design choice.

                    1. 22

                      That choice is a total dealbreaker for me. I never use SCM to record development history as it happened, with all the stumbles, experiments, dead-ends, and “oops, forgot a semicolon in the previous commit”. I use it to produce sets of changes that are easy to review and revert if necessary.

                      1. 11

                        I agree, except that I absolutely do use local SCM to record all of that nonsense history, so I have the freedom to try different approaches and make mistakes without losing work. Obviously I don’t push all that crap; I clean it up with rebase -i before letting anyone else see it. It baffles me how this could be considered bad practice at all, much less “history written by the victors”.

                        (Edit: I wonder if people are just talking past each other here — perhaps the anti-rebasers think you would rebase after pushing, which would be very rude — and the benefits of rebasing locally while working just don’t occur to them.)

                        1. 5

                          I’ve used fossil in the past and my workflow was to have two trees: one with a “history as it really happened” and one that I rsync the completed work to and commit for a “clean” history. The latter gets shared and later rsynced over the other messy repo since I didn’t care about how I got to the end state.

                          1. 3

                            I did something like that in the olden SVN days. cp -R . ../asdfaasdf was my git stash.

                        2. 8

                          I liked every part of the post except the rebase commentary. Everywhere else it does a great job of comparing fossil to git in terms of design motivation vis-à-vis team size. But for rebasing the criticism waxes philosophical without acknowledging different perspectives.

                          One commentator characterized Git as recording history according to the victors, whereas Fossil records history as it actually happened.

                          To me, a rebasing workflow is analogous to compare-and-swap operations, making development lock-free. I make a change, I try to check in the change, if that fails I back off and retry. The history of my retries is no more permanent than the history of transaction rollbacks in a SQL database.

                          I can see why that history might be useful for small teams, who observe the progress of each other’s branches. But right now at work I have 15 branches on deck, blocked on other teams or on hold while I work on something higher priority. My team doesn’t care about any of those branches until I send them for code review, and they don’t care about any versions of my change except the last one.

                          Depending on the time of day, dozens to hundreds of mainline merges are submitted per second. No one cares about the fully accurate history of every developer’s workflow, the deluge of finalized commits is plenty.

                          Now with all that said, I am 100% convinced by this post to use fossil for personal projects. I have notes I’d love to publish as blog posts, but no motivation to operate a web app, build a static site, or use some hosted solution. And I often do wish I could go back and see my thought process for personal code that I pick up again after months, sometimes years.

                      2. 9

                        This recent lobste.rs comment by the “game of trees” author illustrates some downsides, mostly related to scaling.

                      3. 2

                        I was not aware that fossil was this feature-ful. To be honest having stuff like ticketing integrated is super powerful and really interesting to me. Gonna have to take a deeper look at this

                        1. 1

                          You can use ChiselApp.com to host your repositories. I have a CI/CD plan in the works, but it requires a bit of resources.

                        2. 1

                          Are there any CI/CD services that work with fossil? Or has anybody connected jenkins to fossil successfully? What about checking MRs automatically for build-failures?