I always thought that Git and Fossil address different concerns of the respective underlying projects (Linux kernel work and SQLite corresp.) It's clear that b

I always thought that Git and Fossil address different concerns of the respective underlying projects (Linux kernel work and SQLite corresp.) It's clear that both projects need a revision control to manage changes, yet the requirements seem to diverge. Linux kernel is a massive project with a lot of involved contributors. While SQLite is a tighter team, majority of commits are reasonably by 'drh'. And the codebase itself, of course, is not on the same span scale. As such, my understanding is that Git needed to allow slicing and dicing of various sources of patches so that they could be properly sequenced, tested, reviewed, and integrated (thus index/staging and rebase). On the other hand, SQLite needed an immutable history as part of its exhaustive approach to testing and documentation, and Fossil could also be an excellent testing ground for SQLite too ... and a more cohesive CLI (thus the repo-db, security model, persistent branch names, non-destructive delete etc.). So, just as great Masters do, they created the right tools for their project. AND they shared their tools with the rest of the world, that is us all, for which we are grateful indeed. Now, is Git or Fossil a right tool for your project depends on your needs and choices. Not all projects need the slicing and dicing of the patches, just as not all projects require immutability of the history. If anything, the current reality is that Git became a sort of C of the revision control, just it's possible to have a practical use of it without the need to learn it thoroughly. The requirement to rebase your changes for a PR is rather imposed by project conventions, not the tool. I like to think about Git as being a Swiss knife to carve the wooden blocks of patches, so they fit together. Meanwhile, Fossil is a kind of a handy set of chisels to etch the revisions into the stone tablets of the project.