Fossil versus Git (opens in new tab)

I never had a good experience with mercurial from memory. Docs and examples weren't as good (not that Git was hugely better, but network effects had more resources available). I remember the CLI commands being a small bit more intuitive but as someone new to DVCS at the time (as most people would have been) - it didn't really do anything special to help new users get a handle on the mental model for how it works. I remember Facebook publicly using / backing it, was surprised they didn't do more to promote it.

Before being used by everyone else Git was not used by everyone else.

Fossil is used for one of the most deployed embeddable database. Not sure we can call it "irrelevant".

I get what your message is saying, however words have meaning, and being hyperbolic does not help anyone when we try to bring nuances.

> Mercurial was a better DVCS [...]

Totally agree.

This is why jj is the only other VCS I have been interested in. Compatibility with Git repos is a requirement for me

Gt was not successful because of network effects, but more monkey see monkey do imitation that people are prone to. Whatever is used for big projects must be the best, right?

I have recently returned to Fossil for personal stuff. IMO its better than git for one person projects and small teams. It was designed for a small team. What everyone else uses does not really matter for personal stuff. Nor does it matter if you are working with people willing to try something new. Nor does it matter to someone who can take a decision for a team.

It is also very easy to self host.

I disagree that Mercurial was better. For example Git was always much faster.

Mercurial was not better. Features like rebase /squash are not native to mercurial (even though they since added extensions for this) and the tool had a very rigid view of the commit history. I had all my projects on Mercurial for several years after using SVN, because it felt more similar to SVN and I had no mental concept of why you'd ever want something so crazy as "rebase" - commit histories looked the way I always remembered them looking with SVN, with tons of tiny commits like "fix comma", "fix syntax", and no steady concept of a commit hash linked to a complete, working change, because that was something I had never seen before. Basically I just didn't get it.

Today my workflow is based on git + gerrit code review (which is heavily based around git), or in other areas github pull requests, and there is no such thing as a series of little commits that all hodge-podge together to form a particular change to the code, we tailor changes to be perfect, we push -f to keep each commit in the series to be a full and CI-tested story of a change, then we squash-merge them. My use with git is 100% all day things that were impossible with Mercurial back when I used it, if there are extensions for these things now, they are afterthoughts, git understood these concepts from the beginning.

>Not used by everyone else

I'm so old that I remember people saying that about Linux, PostgreSQL, and AMD processors ;)

I used Mercurial before switching to git. The positive difference from switching was how branches worked. I don’t know the technical details but branches on git felt “lighter” to use and maintain than with Mercurial.

Depends on the project and team

There are plenty of situation in which all that matters is that the people actually building are happy with it and a tool that literally nobody else uses would be fine.

Indeed, for many engineering jobs (software and other) in some industries, it's entirely necessary to create new tools and use extremely specialiased. Good people will learn how to use (and build/improve them).

I'd possibly go as far as arguing that a sign of a good team is willingness to aggressively use the right tool for the job even if it is obscure or something they have to build themselves.

Sure, if you're hoping to get traction with an open source JavaScript library… git and github maybe be pre-requisites, but for projects of a certain sort "reach" and "adoption" by other developers are the most important metric. (Though, SQLite has done just fine with Fossil, so there's probably a degree of overstatement in the idea that it anything has to use git / be on Github.)

It matters until it doesn't. Git is the "lingua franca" but increasingly I see team members use only git integrations in the IDE, the web interface (Azure) or say, the Github desktop client.

Those users wouldn't mind switching to Fossil if the graphical interface is reasonably easy to discover and use.

> Mercurial was a better DVCS launched around the same time as git but it lost out, not because "worse is better" but the network effects spreading out from the of the linux kernel itself.

Yeah. I was using Mercurial and, reluctanctly, had to switch to Git. Now don't get me wrong: I was forced to use both CVS and SVN in a thankfully very distant past so I love Git. But I do miss Mercurial. We switched exactly for the reason you mentioned: Git simply won the market.

Git won, Magit is awesome. Then all the Github and whatnots. It's Git, Git and Git.

And never bet against Linus, either: the world runs on Linux (and that's a good thing) and every tech company in the world uses Git. That's just how it is.

Mercurial was a tiny bit better but not that much better that it'd compensate for the entire ecosystem and people gravitating towards Git.

That’s fine. But it’s fun nonetheless to look at the alternatives, or non-alternatives for a lot of us who aren’t willing to do something else on the side that won’t hit the mainstream anytime soon.

IMO the Zeitgeist here leans a bit too much on saying that

- C is everywhere so [Zig/Rust/Nim/Odin] is out of the question

- Git is everywhere so [VCS] is out

- Only [Tech] can be used in enterprise [[what does this mean?]] so [new tech] is out

All of these can still be discussed. Because it’s not simply theoretical. People make their own Fossil repositories. People make things in [Rust/Zig/Nim/Odin]. And the point about some tech being everywhere has the same discussion points each time. So I’m a bit miffed to see this as the top comment.

> you need to [use Git] to work with everyone else

Programmers use different operating systems, editors, languages - is there any reason we all have to use the same source control tool? We weren’t doing so before Git came along.

Git didn’t win because of Linux. It won because of Github.

I’ve used GitHub and never learned the underlying mechanisms.

It’s not that big of a deal with a good UI. Reality is you just use whatever the people that pay you use.

I remember when two engineers on our staff at $BIGCORP test-drove Git for a month and then gave a lunch-talk about their impressions for anyone who was curious about it. They were in favor of switching to it for local / team workflows. At the time, there would still be a translation layer back to our pre-Git company repo, but they advocated for the extra overhead for the gains in new workflow possibilities. You can guess what happened next.

Git had only been around for a handful of years at the time. If not for people slowly adopting it a little at a time, thus leading to the network effect, Git would not have become the dominant VCS of the day. So yeah, when things like this, JJ, etc come along, it's worth paying attention and keeping an open mind cause any one of them might be the "everything else is irrelevant," tool in fifteen years.

Curious why you think Mercurial was a better product. I used it over a decade ago (coming off SVN) and it seemed to use a lot of similar concepts.

Git kinda requires you to read the git book. But I wouldn't call it "hard to use", once you know how it works most of the things it does are obvious (if occasionally badly named).

And you could probably get rid of like... 90% of things people complain about by just writing better frontend (and some people did that) to same backend

And on top of that agents know git far better than fossil.

Maybe it is true that name is destiny after all.

"Fossil has inbound and outbound Git conversion features, so if you start out using one DVCS and later decide you like the other better, you can easily move your version-controlled file content."

> Everything else is kind of irrelevant. Git is hard to use and awkward to master, but you need to do so anyone to work with everyone else.

People will call me crazy, but you can tell Claude Code what you need with Git on your local repo and it will spit out the terminal incantations, you can also... tell it to run them after you read them.

I want it embedded in git simply to break the hold Github has. We have this fantastic distributed fault-tollerant dvcs that gets funneled though at worse 1 service, at best maybe 3 or 4.

I'd love to clone a repo and be able to view all the reasoning behind commits with the context of issues too. I know the commit message should cover this but sometimes it doesn't, or its too much context, or the context is limited to the opinion of the committer. I think all that information is relevant to projects and should have some chance to live alongside it. Stuff like git-bug exists, but then you still need participation from other people.

I really love the idea of radicle.xyz which is git + p2p + issues & patches (called `COB` - collaborative objects) all in your repo but getting the buy-in of the wider population seems extremely difficult, if not impossible. I think part of the attraction here specifically is nostalgia for me, it feels like its invoking the 90s/00s where it was all a big mesh network, information wanted to be free and you couldn't stop the signal.

Fossil also seems cool but the rest of the world is tied to git and I'm tied to jj now. I guess I really wish git themselves [sic] would push something forward, I think that's the only way it would really get broad acceptance. Forges could adopt it and try and special-sauce parts but still let you push/pull "COB"s.

"Feature creep" is hard to characterize. If the project needs and uses it, is it really "feature creep"?

Or, from Wikipedia, "The definition of what qualifies as "feature creep" varies among end users, where what is perceived as such by some users may be considered practical functionality by others." - https://en.wikipedia.org/wiki/Feature_creep

Hipp (the original SQLite author) also developed his own parser generator (Lemon) and his own editor (e). The former is also used by other projects.

Where do you store the different attributes? In the file-system? How do you manage consistency? Why put up with awkward cron solutions when you have a fully ACID database system right there to work with, which is portable across OSes, including ones which don't have cron?

If it helps any, don't think of it as a VCS but as an SCM system - one which includes version control.

I prefer not to have strict version control over the entire state of all work tickets. It sort of adds friction.

> "Why Git Does Not Use SQLite"

For one, you probably don't want your git repo permanently corrupted if you happen to be running it over an NFS mount.

There is a lot of value in "scattered write-once files" as a storage mechanism.

> this could've been an sqlite db

And yet Fossil doesn't use SQLite for its own data model, just as a blob store with indices.

"Fossil is not Relational": https://fossil-scm.org/home/doc/trunk/www/fossil-is-not-rela...

Well the big difference is that an sqlite db has to be running. Git repos just exist as long as the files are on disk, which I think is a mental model people are very used to by now.

I use it for the web interface. Worth checking out again if you haven't recently.

I spent some time working with jujitsu and found it relatively pleasant... except it doesn't seem at all ready for collaborative use beyond a single working folder.

Sharing the repo state seems impossible without going through the (somewhat painful) multi-step process to tag and push commits into git, and you lose all of the value that jujitsu actually adds (e.g. no evolog, no saved conflicts, no anonymous commits). There is no sharing solution beyond this - no way for me to work on the same working state in two locations beyond rsync the entire folder tree, which is no solution.

A SCM in 2026 that only works locally without being a clunky way of talking to git doesn't seem like a solution ready for prime-time. Maybe the google-internal-only backend systems work better.

My main other pain points were a) zero integration with pre-commit hooks and zero ideas how to do so (yes, CI does this, but it's nice to get all the auto-formatting and sanity checks without pushing, waiting, pulling new commits), and b) Automatically picking up all changes is great except when it doesn't work in which case it is _horrible_ and takes manual unpicking at best. Remembered to add something to .gitignore before doing something in the working directory? Great! Just never ever try to checkout a commit from before you added the .gitignore because now it's permanently absorbed into the repo. Also, if you every accidentally have a secret in your repo directory then that's also permanently in there, as far as I can tell there is no way to manually verify that things are purged and all the commentary on the jujitsu discussion forums were "Just avoid doing this in the first place".

> Git isn't the best but network effects matter.

I think this assertion is too vague and arguably wrong. It's unclear which traits would lead a Git alternative to be claimed as better, and even if those traits, if they exist, are relevant. It's also unclear if the tradeoffs of switching tooling away from Git are worth whatever hypothetical benefit there is to be had.

I would make the bold claim that Git is undoubtedly better than any conceivable alternative, and state that the network effect is a consequence and not a side-effect. Anyone is free to try to argue against it by pointing out concrete arguments.

What do yoh mean by PR? Fossil does not do PRs/MRs/CRs or any code review flow.