It's missing what's sadly the only important difference:
Git: Used by everyone else
Fossil: Not used by everyone else
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.
I wish it wasn't the case, but network effects are really important. 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.
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.
I used Mercurial before Git and found it way more intuitive. I don't have much to say about the documentation, I didn't have a problem with it, but that's not the reason.
It is not just because the CLI is more intuitive, though it plays a big part.
The main reason is that mercurial is more opinionated. On a default setup, only a few commands are available, and none of them let you change the history. If you want more, you have to add an extension. These are built-in, that's just a line in a configuration file, so that's not much of an obstacle, but you have to be deliberate. It gives a natural progression, and it better defines the project organization.
With git, you have everything and the kitchen sink, literally, as it uses the "plumbing" and "porcelain" metaphor. All flavors of merge, rebase and fast forward are available, there is a git-reset command that does a dozen of different things, there is stash, the staging area, etc... The first month or two on git, I was a bit overwhelmed, none of that with Mercurial, and I already had the experience of Mercurial when I switched to git, so I was familiar with the concept of push/pull and DAGs.
Now, I tend to prefer git, though after many years, I still have trouble wrapping my head around the command line sometimes. But that's for the same reason it was so hard to me to get into it. It gives out a lot of freedom and possibilities. For example, I like the fact it is really decentralized, for example in one project the customer had a completely separate central repository we couldn't access, and they couldn't access ours, for security reasons. We worked by exchanging bundle files. At some point we also took advantage of the fact that it is possible to have more than one root commit. Also, almost all mistakes are fixable and it is hard to really lose anything (including secrets, so beware!).
For a video game analogy, Mercurial introduces you to new game mechanics as you progress, while Git makes you start in the middle of the map with all the skills unlocked.
Facebook moved to mercurial because of specific problems related to the size of their monorepo. Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit and was open to the help. But all that said if you don’t have a truly enormous monorepo like Facebook or Google then git is arguably the better tool given the network effects. I don’t think Facebook wanted to promote Mecurial as some vastly superior solution outside because for most people it isn’t.
From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:
So, neither Mercurial-out-of-the-box nor Git-out-of-the-box could handle huge monorepos. But Mercurial's willingness to make some modifications made it easier for Facebook to integrated their custom tooling to avoid the slow Big-O O(n) scans for changed files.
> From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:
Facebook moved from subversion to git around 2008. Some of their teams then switched to mercurial around 2014 (I could be wrong by a couple years here or there). By 2014, git was already the main tool everyone was using —- no amount of backing by a single company would have tilted the scales.
I think the massive difference is the number of people using the project vs. contributing to the project. How many people contribute to SQLite vs the Linux kernel. AFAIK not many for the former.
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.
My favorite thing about jj is that it takes the mental model of Git that makes sense (it's a DAG of commits, with references to some commits for metadata like tags & branch names) and just uses that. Instead of the actual full data model of Git which has several unnecessary complications like the index & mandatory branch names. It's much easier to reason about.
Tried jj several weeks ago... and absolutely love it.
A life non-goal for me is becoming proficient in a version control system and Git, insofar as I've been able to tell, demands that you become proficient in an uncomfortably large subset of its features in order to get through any workload, even in the simplest realistic cases.
jj did take some getting use to, but after a couple days it was all sorted and actions which terrified me in Git felt natural and safe using jj. The kind of things that required me to go back to the git documentation (or stackoverflow, or some blog posts) to be sure I was holding it right... in jj it comes easily and naturally.
That jj offers sufficient power under a simple interface to get through the day ... while being compatible with those that use Git... make it a no-brainer for me.
Just rename root directory of project and double size of your repo
Mercurial didn't supported rename, and did delete/add instead, so size of repo grows pretty fast
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.)
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.
> 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.
You could make that argument about HTTP, SMTP, Slack, or the English language. It turns out that yes, the actual concrete points of collaborative interaction do need to be standardised to a degree, unless you're thinking of everyone shouting into their particularly flavoured void, with no means of communicating. You can have different clients speaking the same protocol, but you can't have different protocols.
Even before git, you generally had to use what your team was using, or the FOSS project you were trying to contribute to. So it's kind of a moot point.
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.
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
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.
Features don't matter as much as workflows matter. If they can swap to a Fossil integration for their IDE and their workflow doesn't change (or maybe only changes to click a different icon), it'll be much easier to switch and thus more people will be able to switch.
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.
"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."
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.
As a native son of git, I’m curious what the idiomatic way to maintain a patched fork was without rebase? Would you simply have your “patched” branch and merge in upstream changes as they arrive?
as I recall, you didn't! you just had branches full of dozens of commits for every little bit of the change. yes you'd have to merge continuously to stay up to date.
hg sees history as useful metadata, and therefore you shouldn't dress it up artificially.
git allows for folks to be Pinky's out with their commit history for warm an fuzzies.
If you think editing history is a grand idea that should be used regularly (like with rebase) then I already know you likely haven't been responsible for large mature code base. Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.
There's a huge divide between abusing rebase in horrible ways to modify published history, and using it to clean up a patch series you've been working on.
Oops, I made a mistake two commits ago, I'd really like to get some dumb print statements I added out before I send this off to get merged is perfectly valid, I just did it yesterday. A quick `git commit --fixup` followed by `git rebase -i --autosquash HEAD^3` and I had some dumb debugging code I left in stripped out.
Then, there's other perfectly valid uses of rebase, like a simple `git rebase main` in an active development branch to reparent my commits on the current HEAD instead of having my log messed up with a dozen merge commits as I try to keep the branch both current and ready to merge.
So, yes, I do think editing history is a grand idea that should be used regularly. It lets me make all the stupid "trying this" and "stupid bug" commits I want, without polluting the global history.
Or, are you telling me you've also never ended up working on two separate tasks in a branch, thinking they would be hard to separate into isolated changes, and they ended up being more discrete than you expected so you could submit them as two separate changes with a little help from `git cherry-pick` and `git rebase` too?
Editing history isn't evil. Editing history such that pulls from your repository break? That's a different story entirely.
Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them.
What's it matter if you have an extra commit to remove a file before merge? Perfectly valid, and doesn't hide anything.
Caring more about a "visually pleasing log" when you can care about an information rich log doesn't jive with me. Logs aren't supposed to be "clean"
If I want features in two branches, I make two branches. Cherry pick also is bad for most people, most of the time.
I care about having a commit log that's useful and easy to scan through, it's not about it being "visually pleasing". Having a dozen "oopsie" commits in the log doesn't make my life any easier down the road, all it does is increase noise in the history.
Again, once something hits `main` or a release/maintenance branch then history gets left the hell alone. But there really is no context to be gained from me fixing stupid things like typos, stripping out printf() debug statements, etc. being in the commit logs before a change gets merged.
> Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them.
You're already deciding what information is important to the future when you decide at which points you commit.
Reductio ad absurdum: why not commit every keystroke, including back spaces? By not including every key stroke, you are hiding information from future people!
When using systems without history editing I simply make an order of magnitude fewer commits. With git I basically commit every few minutes and then edit later, and with not-git I simply don't commit until it's "ready". Either way all of those intermediate states aren't getting published or saved forever.
> Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.
see that's a common story from a legacy way of working, back when everyone wrote perl / php scripts and shoved it all into a repo.
The way that people years from now understand what someone else did is that when that someone else does the thing, it's presented for code review. That is, your patch does not go in at all if nobody else knows how it works. You present each change as a logical series of commits, without lots of noise like "fixed typo" or "oops forgot this test", just the way people present patches on the LKML (this is why Linus "got it" before anyone else did), and then other people review it, which is where it's established, "this change makes sense, I understand why and how you did it, and it has good tests".
When you work on a project that is truly long term, you yourself need these records to understand what you did 10 or 15 years ago. So there's no issue that short term history was modified, this is actually essential, because what you're doing is editing the story of how a change came about and presenting it for review. Having it be a long series of small commits that sometimes reverse each other is not going to help anyone understand a particular feature or change, it's noise.
I'm not sure what XP you're speaking from, I see modern day companies with all faults of orgs past because the tooling isn't saving anyone from the human tendencies.
If your problem with commit history is that folks have too many useless commits and you can't personally be bothered to focus on the meat of the PR, that'sa probablem with the commit author and PR reviewer. Not a fundamental need to prune logs.
> 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.
> 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.
> Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, technical notes, a web forum, and a chat service [...]
I like the idea of having all of those within the actual VCS, mostly because with Git you need centralized services like GitHub to provide that.
But I have to ask: Is it really a good idea? Seems like feature creep motivated by the wants of a single project (SQLite).
All of those could be (albeit awkwardly) backed with a git repo and a cron job.
Wiki? Just make a repo with a bunch of Markdown or this-week's-favorate-markup-language files.
Ticketing & bug tracking? Again, just a Markdown file for every ticket.
Embedded documentation & technical notes? Those are just special wiki pages with different attributes.
Forum and chat service? Do you want your VCS to do that? I get being able to hyperlink between files and conversations, but still.
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.
> Stuff like git-bug exists, but then you still need participation from other people.
The plan is to 1) finish the webUI and 2) accept external auth (e.g. github OAuth). Once done, anyone can trivially host publicly their own forge and accept public contribution without any buy-in effort. Then, if user wants to go native they just install git-bug locally.
Whoa, git-bug is still being developed, awesome! I wonder how difficult it would be to add other tables to it (I cannot help but think about bug trackers as being a database with a frontend like Access, and many limitations...) — in particular to have Messages (for messages) and Discussions (for hierarchical list of message references). Now that git has reftable maybe this sort of abuse would actually work...
Assuming that by "table" you mean another "document type" ... pretty easily. There is a reusable CRDT like datastructure that you can use to define your own thing. You do that by defining the operations that can happen on it and what they do.
You don't have to handle the interaction with git or the conflict resolution.
"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.
Amusingly there exists a "Why SQLite Does Not Use Git" article (https://sqlite.org/whynotgit.html), but there is no corresponding "Why Git Does Not Use SQLite".
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.
Sqlite does not have a server component (although there may be other projects that do provide sqlite as a server). Sqlite files are also just files on the disk.
It still looks _exactly_ the same way as a decade ago (well, there were some CSS tweaks). I used to use it for my own projects until friction overcame my tastes, but I remember one of the things I really didn't like about it was that the web interface was _so_ dated. I love Gitea because it feels a lot like GitHub (and hence I don't have to remember where things are).
Edit: Wow, it supports markdown now? and a forum? OK...
The infrastructure around fossil and jujitsu are missing. Git isn't the best but network effects matter.
For example, we use jenkins at work and there is no plugin for fossil or jujitsu.
Every customer we have uses git so we can't even propose fossil. Even though we might use only 10 git commands, those commands are universally known by all to work if something goes wrong.
It isn't sufficient to say that fossil or jujitsu are better. The ecosystem and mindshare for an alternative DVCS is significantly lacking unfortunately.
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".
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.
Git is only better in the same sense that Windows is better than Linux. I really need the tools I use that only run on Windows. I prefer Linux for a lot of things, including daily web development, but the experience of developing Unreal Engine on Linux is lacking. I love fossil and the many features it provides in itself and would use it for everything, except that it doesn't have (working) Intellij plugin for integration, a good GitHub alternative, etc.
fossil is really cool for the simple fact that you get your issues, tickets and wiki all stored in an SQLite DB. Feels neat and I wish I had more occasions to use it.
I would not want to use fossil at work and I do not know if it could handle projects of that size. Would require manyears of rewriting tools that would not be realistic.
For my hobby projects I have used fossil for several years. It works great and I do not miss anything from git. It's simpler and just nicer to use.
If nothing else I felt like using the same version control system for over 10 years was getting boring. Needed something new to play with. See things from a new perspective. Like playing with a new programming language now and then, even when it is something I do not expect to get much real use out of.
Brings me back... I did use Fossil in 2010, cf my notes on https://fabien.benetou.fr/Tools/Fossil but like most I only switched due to the popularity of git, not because any specific feature was missing.
Fossil has some really nice ideas (although I don't like the feature bloat), but when I tried to use it I ran into so many issues and/or bugs. With git on the other hand I can't remember ever hitting a bug in decades.
I don't really like git that much, but it works pretty well most of the time.
I actually use fossil all the time for my projects. It just makes more sense to me in the way it works and the ease of use. And you can self host your repos with ease, for example [1]
For practical cases `git worktree` allows to have multiple checkouts. Document marks this section as "partly disputed" with an external link. IMHO git worktrees has the same ergonomics as in fossil. This section kinda discredits the rest of the article.
Your alternative is... what exactly? A unique and baroque file format for each application (see: Git)? Folders of JSON or markdown files which are slow, easily corrupted, and lack indexing? Depend on some memory-heavy external DB service like Postgres?
In most cases, embedding SQLite is the best solution. And that is exactly what it was designed for.
Also, what are they talking about with "POSIX systems", is this a really old SCM? I've been using git natively on Windows for so many years, I don't remember how many.
Either way, any new SCM needs to interoperate or easily convert git repos if it wants mass adaption. I don't think git is programmatic enough, it can get really obese really fast (even with pruning/gc), it would be great if client-side "plugins" were a thing pushed by remotes (for things like secret scanning, linting), and I do agree that something like sqlite as a back-end would suit it better for performance. I would want newer gits to really be thought as more than an SCM. People are using it to manage all kinds of state. You can run countries with the dam thing! :), and some are trying.
I've thought about distributed-ledgers using git too, with or to replace block-chains.
It's missing what's sadly the only important difference:
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.I wish it wasn't the case, but network effects are really important. 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.
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.
I used Mercurial before Git and found it way more intuitive. I don't have much to say about the documentation, I didn't have a problem with it, but that's not the reason.
It is not just because the CLI is more intuitive, though it plays a big part.
The main reason is that mercurial is more opinionated. On a default setup, only a few commands are available, and none of them let you change the history. If you want more, you have to add an extension. These are built-in, that's just a line in a configuration file, so that's not much of an obstacle, but you have to be deliberate. It gives a natural progression, and it better defines the project organization.
With git, you have everything and the kitchen sink, literally, as it uses the "plumbing" and "porcelain" metaphor. All flavors of merge, rebase and fast forward are available, there is a git-reset command that does a dozen of different things, there is stash, the staging area, etc... The first month or two on git, I was a bit overwhelmed, none of that with Mercurial, and I already had the experience of Mercurial when I switched to git, so I was familiar with the concept of push/pull and DAGs.
Now, I tend to prefer git, though after many years, I still have trouble wrapping my head around the command line sometimes. But that's for the same reason it was so hard to me to get into it. It gives out a lot of freedom and possibilities. For example, I like the fact it is really decentralized, for example in one project the customer had a completely separate central repository we couldn't access, and they couldn't access ours, for security reasons. We worked by exchanging bundle files. At some point we also took advantage of the fact that it is possible to have more than one root commit. Also, almost all mistakes are fixable and it is hard to really lose anything (including secrets, so beware!).
For a video game analogy, Mercurial introduces you to new game mechanics as you progress, while Git makes you start in the middle of the map with all the skills unlocked.
Facebook moved to mercurial because of specific problems related to the size of their monorepo. Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit and was open to the help. But all that said if you don’t have a truly enormous monorepo like Facebook or Google then git is arguably the better tool given the network effects. I don’t think Facebook wanted to promote Mecurial as some vastly superior solution outside because for most people it isn’t.
>Moreover the git maintainers were unwilling to work with Facebook to improve git to solve some of these problems. Mercurial was a better fit
More add-on discussion including Microsoft+Git spurred by your previous comment about this: https://news.ycombinator.com/item?id=15725497
From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:
https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...
So, neither Mercurial-out-of-the-box nor Git-out-of-the-box could handle huge monorepos. But Mercurial's willingness to make some modifications made it easier for Facebook to integrated their custom tooling to avoid the slow Big-O O(n) scans for changed files.
> From the Facebook blog post, it seems like the key issue was Facebook's internal filesystem monitoring tool (Watchman) was easier to integrate with Mercurial than with Git:
> https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...
That link is from 2014, is there any more recent work to make Git use a file watcher rather than scan the whole tree?
Facebook moved from subversion to git around 2008. Some of their teams then switched to mercurial around 2014 (I could be wrong by a couple years here or there). By 2014, git was already the main tool everyone was using —- no amount of backing by a single company would have tilted the scales.
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.
I think the massive difference is the number of people using the project vs. contributing to the project. How many people contribute to SQLite vs the Linux kernel. AFAIK not many for the former.
SQLite doesn't accept external contributions, and the dev team recently consisted of three people.
In other words: its use of any specific VCS is pretty much irrelevant.
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.
[dead]
This is why jj is the only other VCS I have been interested in. Compatibility with Git repos is a requirement for me
My favorite thing about jj is that it takes the mental model of Git that makes sense (it's a DAG of commits, with references to some commits for metadata like tags & branch names) and just uses that. Instead of the actual full data model of Git which has several unnecessary complications like the index & mandatory branch names. It's much easier to reason about.
Tried jj several weeks ago... and absolutely love it.
A life non-goal for me is becoming proficient in a version control system and Git, insofar as I've been able to tell, demands that you become proficient in an uncomfortably large subset of its features in order to get through any workload, even in the simplest realistic cases.
jj did take some getting use to, but after a couple days it was all sorted and actions which terrified me in Git felt natural and safe using jj. The kind of things that required me to go back to the git documentation (or stackoverflow, or some blog posts) to be sure I was holding it right... in jj it comes easily and naturally.
That jj offers sufficient power under a simple interface to get through the day ... while being compatible with those that use Git... make it a no-brainer for me.
I disagree that Mercurial was better. For example Git was always much faster.
I remember that: for repos ~ 1Gb Mercurial just became unusable. It took half of day just to clone the repo.
That sounds like y'all may have been storing binary blobs and large files with out the right plugins setup.
Just rename root directory of project and double size of your repo Mercurial didn't supported rename, and did delete/add instead, so size of repo grows pretty fast
>Not used by everyone else
I'm so old that I remember people saying that about Linux, PostgreSQL, and AMD processors ;)
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.)
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.
Mercurial introduced bookmarks,it was something similar to git branches. But it was already too late, GitHub and Linus' weight did the rest.
Bookmarks was there, like in 2012, but no one bothered to read the docs, and everyone continue to use heavy, non removable branches.
> 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.
You could make that argument about HTTP, SMTP, Slack, or the English language. It turns out that yes, the actual concrete points of collaborative interaction do need to be standardised to a degree, unless you're thinking of everyone shouting into their particularly flavoured void, with no means of communicating. You can have different clients speaking the same protocol, but you can't have different protocols.
Even before git, you generally had to use what your team was using, or the FOSS project you were trying to contribute to. So it's kind of a moot point.
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
Git didn’t win because of Linux. It won because of Github.
s/didn't win/isn't winning/
Nothing is forever (and Microsoft owns Github now, so if I were a betting man…)
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.
Features don't matter as much as workflows matter. If they can swap to a Fossil integration for their IDE and their workflow doesn't change (or maybe only changes to click a different icon), it'll be much easier to switch and thus more people will be able to switch.
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.
"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."
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.
As a native son of git, I’m curious what the idiomatic way to maintain a patched fork was without rebase? Would you simply have your “patched” branch and merge in upstream changes as they arrive?
as I recall, you didn't! you just had branches full of dozens of commits for every little bit of the change. yes you'd have to merge continuously to stay up to date.
hg sees history as useful metadata, and therefore you shouldn't dress it up artificially.
git allows for folks to be Pinky's out with their commit history for warm an fuzzies.
If you think editing history is a grand idea that should be used regularly (like with rebase) then I already know you likely haven't been responsible for large mature code base. Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.
There's a huge divide between abusing rebase in horrible ways to modify published history, and using it to clean up a patch series you've been working on.
Oops, I made a mistake two commits ago, I'd really like to get some dumb print statements I added out before I send this off to get merged is perfectly valid, I just did it yesterday. A quick `git commit --fixup` followed by `git rebase -i --autosquash HEAD^3` and I had some dumb debugging code I left in stripped out.
Then, there's other perfectly valid uses of rebase, like a simple `git rebase main` in an active development branch to reparent my commits on the current HEAD instead of having my log messed up with a dozen merge commits as I try to keep the branch both current and ready to merge.
So, yes, I do think editing history is a grand idea that should be used regularly. It lets me make all the stupid "trying this" and "stupid bug" commits I want, without polluting the global history.
Or, are you telling me you've also never ended up working on two separate tasks in a branch, thinking they would be hard to separate into isolated changes, and they ended up being more discrete than you expected so you could submit them as two separate changes with a little help from `git cherry-pick` and `git rebase` too?
Editing history isn't evil. Editing history such that pulls from your repository break? That's a different story entirely.
Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them. What's it matter if you have an extra commit to remove a file before merge? Perfectly valid, and doesn't hide anything.
Caring more about a "visually pleasing log" when you can care about an information rich log doesn't jive with me. Logs aren't supposed to be "clean"
If I want features in two branches, I make two branches. Cherry pick also is bad for most people, most of the time.
I care about having a commit log that's useful and easy to scan through, it's not about it being "visually pleasing". Having a dozen "oopsie" commits in the log doesn't make my life any easier down the road, all it does is increase noise in the history.
Again, once something hits `main` or a release/maintenance branch then history gets left the hell alone. But there really is no context to be gained from me fixing stupid things like typos, stripping out printf() debug statements, etc. being in the commit logs before a change gets merged.
> Editing history let's people hide information, intentionally or not. You are bold to claim you know what future people need information wise better than them.
You're already deciding what information is important to the future when you decide at which points you commit.
Reductio ad absurdum: why not commit every keystroke, including back spaces? By not including every key stroke, you are hiding information from future people!
When using systems without history editing I simply make an order of magnitude fewer commits. With git I basically commit every few minutes and then edit later, and with not-git I simply don't commit until it's "ready". Either way all of those intermediate states aren't getting published or saved forever.
you might want to check on what you "know" then....
[flagged]
Nice technical argument you've got here.
What's your excuse then?
just so you know, this line
> Where you'd rather have every comment, change and scrap of info available to understand what you're trying to maintain because the folks before you are long gone.
see that's a common story from a legacy way of working, back when everyone wrote perl / php scripts and shoved it all into a repo.
The way that people years from now understand what someone else did is that when that someone else does the thing, it's presented for code review. That is, your patch does not go in at all if nobody else knows how it works. You present each change as a logical series of commits, without lots of noise like "fixed typo" or "oops forgot this test", just the way people present patches on the LKML (this is why Linus "got it" before anyone else did), and then other people review it, which is where it's established, "this change makes sense, I understand why and how you did it, and it has good tests".
When you work on a project that is truly long term, you yourself need these records to understand what you did 10 or 15 years ago. So there's no issue that short term history was modified, this is actually essential, because what you're doing is editing the story of how a change came about and presenting it for review. Having it be a long series of small commits that sometimes reverse each other is not going to help anyone understand a particular feature or change, it's noise.
I'm not sure what XP you're speaking from, I see modern day companies with all faults of orgs past because the tooling isn't saving anyone from the human tendencies.
If your problem with commit history is that folks have too many useless commits and you can't personally be bothered to focus on the meat of the PR, that'sa probablem with the commit author and PR reviewer. Not a fundamental need to prune logs.
> 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.
And on top of that agents know git far better than fossil.
Maybe it is true that name is destiny after all.
> agents know git far better than fossil.
That does not matter though. If you need an AI agent for SCM you are already lost and should take a step back.
> 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’d rather understand what my computer is doing than hope that fancy autocomplete happens to do the right thing.
> Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, technical notes, a web forum, and a chat service [...]
I like the idea of having all of those within the actual VCS, mostly because with Git you need centralized services like GitHub to provide that.
But I have to ask: Is it really a good idea? Seems like feature creep motivated by the wants of a single project (SQLite).
All of those could be (albeit awkwardly) backed with a git repo and a cron job. Wiki? Just make a repo with a bunch of Markdown or this-week's-favorate-markup-language files. Ticketing & bug tracking? Again, just a Markdown file for every ticket. Embedded documentation & technical notes? Those are just special wiki pages with different attributes. Forum and chat service? Do you want your VCS to do that? I get being able to hyperlink between files and conversations, but still.
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.
> Stuff like git-bug exists, but then you still need participation from other people.
The plan is to 1) finish the webUI and 2) accept external auth (e.g. github OAuth). Once done, anyone can trivially host publicly their own forge and accept public contribution without any buy-in effort. Then, if user wants to go native they just install git-bug locally.
Whoa, git-bug is still being developed, awesome! I wonder how difficult it would be to add other tables to it (I cannot help but think about bug trackers as being a database with a frontend like Access, and many limitations...) — in particular to have Messages (for messages) and Discussions (for hierarchical list of message references). Now that git has reftable maybe this sort of abuse would actually work...
Assuming that by "table" you mean another "document type" ... pretty easily. There is a reusable CRDT like datastructure that you can use to define your own thing. You do that by defining the operations that can happen on it and what they do. You don't have to handle the interaction with git or the conflict resolution.
"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.
I was tinkering with writing my own .git parser recently, and I couldn't help thinking "this could've been an sqlite db".
I found https://github.com/chrislloyd/git-remote-sqlite as a way to achieve git-on-sqlite, which works by registering itself as a git "remote" helper.
Amusingly there exists a "Why SQLite Does Not Use Git" article (https://sqlite.org/whynotgit.html), but there is no corresponding "Why Git Does Not Use SQLite".
> "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.
No, the whole magic of sqlite is that it is also just file-on-disk.
Huh I didn't know that. Thanks for the correction.
Sqlite does not have a server component (although there may be other projects that do provide sqlite as a server). Sqlite files are also just files on the disk.
It still looks _exactly_ the same way as a decade ago (well, there were some CSS tweaks). I used to use it for my own projects until friction overcame my tastes, but I remember one of the things I really didn't like about it was that the web interface was _so_ dated. I love Gitea because it feels a lot like GitHub (and hence I don't have to remember where things are).
Edit: Wow, it supports markdown now? and a forum? OK...
I use it for the web interface. Worth checking out again if you haven't recently.
The infrastructure around fossil and jujitsu are missing. Git isn't the best but network effects matter. For example, we use jenkins at work and there is no plugin for fossil or jujitsu. Every customer we have uses git so we can't even propose fossil. Even though we might use only 10 git commands, those commands are universally known by all to work if something goes wrong. It isn't sufficient to say that fossil or jujitsu are better. The ecosystem and mindshare for an alternative DVCS is significantly lacking unfortunately.
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.
Git is only better in the same sense that Windows is better than Linux. I really need the tools I use that only run on Windows. I prefer Linux for a lot of things, including daily web development, but the experience of developing Unreal Engine on Linux is lacking. I love fossil and the many features it provides in itself and would use it for everything, except that it doesn't have (working) Intellij plugin for integration, a good GitHub alternative, etc.
fossil is really cool for the simple fact that you get your issues, tickets and wiki all stored in an SQLite DB. Feels neat and I wish I had more occasions to use it.
What do yoh mean by PR? Fossil does not do PRs/MRs/CRs or any code review flow.
Yes indeed, I updated to the right terminology.
I would not want to use fossil at work and I do not know if it could handle projects of that size. Would require manyears of rewriting tools that would not be realistic.
For my hobby projects I have used fossil for several years. It works great and I do not miss anything from git. It's simpler and just nicer to use.
If nothing else I felt like using the same version control system for over 10 years was getting boring. Needed something new to play with. See things from a new perspective. Like playing with a new programming language now and then, even when it is something I do not expect to get much real use out of.
Brings me back... I did use Fossil in 2010, cf my notes on https://fabien.benetou.fr/Tools/Fossil but like most I only switched due to the popularity of git, not because any specific feature was missing.
Fossil has some really nice ideas (although I don't like the feature bloat), but when I tried to use it I ran into so many issues and/or bugs. With git on the other hand I can't remember ever hitting a bug in decades.
I don't really like git that much, but it works pretty well most of the time.
I actually use fossil all the time for my projects. It just makes more sense to me in the way it works and the ease of use. And you can self host your repos with ease, for example [1]
[1]: https://hdrz.cc/museum/bagatto-bearblog
> 2.6 One vs. Many Check-outs per Repository
For practical cases `git worktree` allows to have multiple checkouts. Document marks this section as "partly disputed" with an external link. IMHO git worktrees has the same ergonomics as in fossil. This section kinda discredits the rest of the article.
If you want to understand the implementation, the DeepWiki documentation is very helpful:
https://deepwiki.com/drhsqlite/fossil-mirror/
radicle does some project mgmt inside dotgit directory. there are other projects doing similar.
jj simplifies git.
real alternative to fossil.
Fossil is my goto Customer Documentation tool, Code, Wiki etc all in one file that i can give to the Customer.
However for pure Code/Bin-repos....i miss Bitkeeper :-(
One check-out per repository Many check-outs per repository
There are Git work trees so I can make many checkouts per repository.
i'm a 99 percenter normie and i settled on fossil a couple years ago. A comfy toolset that i can actually use.
whereas with git, i can clone/install using a gui tool. And that's about it.
We use mercurial and are happy with it. I hope we never move to git, but I can see us eventually moving to whatever is next.
[dead]
[dead]
[flagged]
Your alternative is... what exactly? A unique and baroque file format for each application (see: Git)? Folders of JSON or markdown files which are slow, easily corrupted, and lack indexing? Depend on some memory-heavy external DB service like Postgres?
In most cases, embedding SQLite is the best solution. And that is exactly what it was designed for.
If you only knew how much SQLite is used...
* Apple Mail ( "~/Library/Mail/V5/MailData/Envelope Index" )
* Legacy database in Android
* Firefox, Thunderbird
* Google Chrome, Edge
It is quick, simple, reliable and have enough performance for it's use case. Instead of using text files or develop own database formats.
This is the single worst project to make that comment.
tbh I don't think that really counts when it is a tool made by the sqlite developer.
sqlite is not a heavyweight database, it's a fopen() wrapper
> Commit first
pre-commit hooks?
Also, what are they talking about with "POSIX systems", is this a really old SCM? I've been using git natively on Windows for so many years, I don't remember how many.
Either way, any new SCM needs to interoperate or easily convert git repos if it wants mass adaption. I don't think git is programmatic enough, it can get really obese really fast (even with pruning/gc), it would be great if client-side "plugins" were a thing pushed by remotes (for things like secret scanning, linting), and I do agree that something like sqlite as a back-end would suit it better for performance. I would want newer gits to really be thought as more than an SCM. People are using it to manage all kinds of state. You can run countries with the dam thing! :), and some are trying.
I've thought about distributed-ledgers using git too, with or to replace block-chains.