The feature sets of Fossil andGit overlap inmany ways. Both aredistributedversion control systems which store a tree of check-in objects to alocal repository clone. In both systems, the local clone starts out as afull copy of the remote parent. New content gets added to the localclone and then later optionally pushed up to the remote, and changes tothe remote can be pulled down to the local clone at will. Both systemsoffer diffing, patching, branching, merging, cherry-picking, bisecting,private branches, a stash, etc.
Fossil has inbound and outbound Git conversion features, so if you startout using one DVCS and later decide you like the other better, you caneasilymove your version-controlled file content.¹
In this document, we set all of that similarity and interoperabilityaside and focus on the important differences between the two, especiallythose that impact the user experience.
Keep in mind that you are reading this on a Fossil website, and thoughwe try to be fair, the information heremight be biased in favor of Fossil, if only because we spend most of ourtime using Fossil, not Git. Ask around for second opinions frompeople who have usedboth Fossil and Git.
If you want a more practical, less philosophical guide to moving fromGit to Fossil, see ourGit to Fossil Translation Guide.
Differences between Fossil and Git are summarized by the following table,with further description in the text that follows.
| GIT | FOSSIL | more |
|---|---|---|
| File versioning only | VCS, tickets, wiki, docs, notes, forum, chat, UI,RBAC | 2.1 ↓ |
| A federation of many small programs | One self-contained, stand-alone executable | 2.2 ↓ |
| Custom key/value data store | The most used SQL database in the world | 2.3 ↓ |
| Runs natively on POSIX systems | Runs natively on both POSIX and Windows | 2.4 ↓ |
| Bazaar-style development | Cathedral-style development | 2.5.1 ↓ |
| Designed for Linux kernel development | Designed for SQLite development | 2.5.2 ↓ |
| Focus on individual branches | Focus on the entire tree of changes | 2.5.3 ↓ |
| One check-out per repository | Many check-outs per repository | 2.6 ↓ |
| Remembers what you should have done | Remembers what you actually did | 2.7 ↓ |
| Commit first | Test first | 2.8 ↓ |
| SHA-1 or SHA-2 | SHA-1 and/or SHA-3, in the same repository | 2.9 ↓ |
Git provides file versioning services only, whereas Fossil addsan integratedwiki,ticketing & bug tracking,embedded documentation,technical notes, aweb forum,and achat service,all within a single nicely-designedskinnable webUI,protected bya fine-grained role-basedaccess control system.These additional capabilities are available for Git as 3rd-partyadd-ons, but with Fossil they are integrated intothe design, to the point that it approximates"GitHub-in-a-box."
Even if you only want straight version control, Fossil has affordancesnot available in Git.
For instance, Fossil can do operations over all local repo clones andcheck-out directories with a single command. You can say "fossilall sync" on a laptop prior to taking it off the network hostingthose repos, as before going on a trip. It doesn't matter if thoserepos are private and restricted to your company network or publicInternet-hosted repos, you get synced up with everything you need whileoff-network.
You get the same capability with several other Fossilsub-commands as well, such as "fossil all changes" to get a list of filesthat you forgot to commit prior to the end of your working day, acrossall repos.
Whenever Fossil is told to modify the local checkout in some destructiveway (fossil rm,fossil update,fossil revert, etc.) Fossil remembers the prior stateand is able to return the check-out directory to that state with afossil undo command. While you cannot undo a commit in Fossil—on purpose! — as long as the change remains confined tothe local check-out directory only, Fossil makes undoeasier than inGit.
For developers who choose to self-host projects rather than rely on a3rd-party service such as GitHub, Fossil is much easier to set up:the stand-alone Fossil executable together with a2-line CGI scriptsuffice to instantiate a full-featured developer website. To accomplishthe same using Git requires locating, installing, configuring, integrating,and managing a wide assortment of separate tools. Standing up a developerwebsite using Fossil can be done in minutes, whereas doing the same usingGit requires hours or days.
Fossil is small, complete, and self-contained. If you cloneGit's self-hosting repository, you get justGit's source code. If you clone Fossil's self-hosting repository, youget the entire Fossil website — source code, documentation, tickethistory, and so forth.² That means you get a copy of this very articleand all of its historical versions, plus the same for all of the otherpublic content on this site.
Git is actually a collection of many small tools, each doing one smallpart of the job, which can be recombined (by experts) to performpowerful operations. Git has a lot of complexity and many dependencies,so that most people end up installing it via some kind of packagemanager, simply because the creation of complicated binary packages isbest delegated to people skilled in their creation. Normal Git users arenot expected to build Git from source and install it themselves.
Fossil is a single self-contained stand-alone executable whichdepends only on common platform libraries in its default configuration.To install one ofourprecompiled binaries, unpack the executable from the archive and put itsomewhere in yourPATH. To uninstall it, delete the executable.
This policy is particularly useful when running Fossil inside arestrictive container, anything fromclassic chrootjails to modernOS-level virtualization mechanisms such asDocker.Ourstock container image is under 8 MB whenuncompressed and running. It contains nothing but a singlestatically-linked binary.
If you build a dynamically linked binary instead, Fossil's on-disk sizedrops to around 6 MB, and it's dependent only on widespreadplatform libraries with stable ABIs such as glibc, zlib, and openssl.
Full static linking is easier on Windows, so our precompiled Windowsbinaries are just a ZIP archivecontaining only "fossil.exe". There is no "setup.exe"to run.
Fossil is easy to build from sources. Just run"./configure && make" on POSIX systems and"nmake /f Makefile.msc" on Windows.
Contrast a basic installation of Git, which takes up about15 MiB on Debian 10 across 230 files, not counting the contents of/usr/share/doc or/usr/share/locale. If you need todeploy to any platform where you cannot count on facilities like the POSIXshell, Perl interpreter, and Tcl/Tk platform needed to fully use Gitas part of the base platform, the full footprint of a Git installationextends to more like 45 MiB and thousands of files. This complicatesseveral common scenarios: Git for Windows, chrooted Git servers,Docker images...
Some say that Git more closely adheres to the Unix philosophy,summarized as "many small tools, loosely joined," but we have manyexamples of other successful Unix software that violates that principleto good effect, from Apache to Python to ZFS. We can infer from thatthat this is not an absolute principle of good software design.Sometimes "many features, tightly-coupled" works better. What actuallymatters is effectiveness and efficiency. We believe Fossil achievesthis.
The above size comparisons aren't apples-to-apples anyway. We'vecompared the size of Fossil with all of itsmany built-infeatures to a fairly minimal Git installation. You must add a lot ofthird-party software to Git to give it a Fossil-equivalent feature set.ConsiderGitLab, a third-party extension toGit wrapping it in many features, making it roughly Fossil-equivalent,thoughmuch moreresource hungry and hence more costly to run than the equivalent Fossilsetup.The official GitLabCommunity Edition container currently clocks in at 2.66 GiB!
GitLab's requirements are easy to accept when you're dedicatinga local rack server or blade to it, since its minimum requirements aremore or less a description of the smallestthing you could call a "server" these days, but when you go to host thatin the cloud, you can expect to pay about 8 times as much to comfortably hostGitLab as for Fossil.³ This difference is largely due to basictechnology choices: Ruby and PostgreSQL vs C and SQLite.
The Fossil project itself ishosted on a small andinexpensive VPS. A bare-bones $5/month VPS or aspare Raspberry Pi is sufficient to run a full-up projectsite, complete with tickets, wiki, chat, and forum, in addition tobeing a code repository.
The baseline data structures for Fossil and Git are the same, moduloformatting details. Both systems manage adirected acyclicgraph (DAG) ofMerkletree structured check-in objects.Check-ins are identified by a cryptographic hash of the check-incontents, and each check-in refers to its parent via the parent's hash.
The difference is that Git stores its objects as individual files in the.git folder or compressed into bespoke key/valuepack-files,whereas Fossil stores its objects in aSQLitedatabase file which provides ACID transactions and a high-level querylanguage.This difference is more than an implementation detail. It has importantpractical consequences.
One notable consequence is that it is difficult to find the descendantsof check-ins in Git.One can easily locate the ancestors of a particular Git check-inby following the pointers embedded in the check-in object, but it isdifficult to go the other direction and locate the descendants of acheck-in. It is so difficult, in fact, that neither native Git norGitHub provide this capability short of crawling thecommit log. With Fossil,on the other hand, finding descendants is a simple SQL query.It is common in Fossil to ask to seeall check-ins since the last release.Git lets you see "what came before". Fossil makes it just aseasy to also see "what came after".
Leaf check-ins in Git that lack a "ref" become "detached," making themdifficult to locate and subject to garbage collection. Thisdetached headstate problem has caused grief formanyGit users. WithFossil, detached heads are simply impossible because we can always findour way back into the Merkle tree using one or more of the relationsin the SQL database.
The SQL query capabilities of Fossil make it easier to track thechanges for one particular file within a project. For example,you can easily findthe complete edit history of this one document,or eventhe same history color-coded by committer,Both questions are simple SQL query in Fossil, with procedural codeonly being used to format the result for display.The same result could be obtained from Git, but because the data isin a key/value store, much more procedural code has to be written towalk the data and compute the result. And since that is a lot morework, the question is seldom asked.
The ease of querying Fossil data using SQL means that status orhistory information about the project under management is easierto obtain. Being easier means that it is more likely to happen.Fossil reports tend to be more detailed and useful.Comparethis Fossil timeline toits closest equivalent in GitHub. Judge for yourself: which of thosereports is more useful to a developer trying to understand what happened?
The bottom line is that even though Fossil and Git are built aroundthe same low-level data structure, the use of SQLto query this data makes the data more accessible in Fossil, resultingin more detailed information being available to the user. Thisimproves situational awareness and makes working on the projecteasier.
Fossil is largely written in ISO C, almost purely conforming to theoriginal 1989 standard. We make very little use ofC99, and we do not knowingly makeany use ofC11. Fossildoes call POSIX and Windows APIs where necessary, but it's aboutas portable as you can ask given that ISO C doesn't define all of thefacilities Fossil needs to do its thing. (Network sockets, file locking,etc.) There are certainly well-known platforms Fossil hasn't been portedto yet, but that's most likely due to lack of interest rather thaninherent difficulties in doing the port. We believe the most stringentlimit on its portability is that it assumes at least a 32-bit CPU andseveral megs of flat-addressed memory.⁴ Fossil isn't quite asportable as SQLite, but it'sclose.
Over half of the C code in Fossil is actually an embedded copy of thecurrent version of SQLite. Much of what is Fossil-specific after you setSQLite itself aside is SQL code calling into SQLite. The number of linesof SQL code in Fossil isn't large by percentage, but since SQL is suchan expressive, declarative language, it has an outsized contribution toFossil's user-visible functionality.
Fossil isn't entirely C and SQL code. Its web UIuses JavaScript wherenecessary. The server-sideUI scripting uses a custom minimalTcl dialect calledTH1, which isembedded into Fossil itself. Fossil's build system and test suite arelargely based on Tcl.⁵ All of this is quite portable.
About half of Git's code is POSIX C, and about a third is POSIX shellcode. This is largely why the so-called "Git for Windows" distributions(bothfirst-party andthird-party) are actually anMSYS POSIX portability environment bundledwith all of the Git stuff, because it would be too painful to port Gitnatively to Windows. Git is a foreign citizen on Windows, speaking to itonly through a translator.⁶
While Fossil does lean toward POSIX norms when given a choice — LF-onlyline endings are treated as first-class citizens over CR+LF, for example— the Windows build of Fossil is truly native.
The third-party extensions to Git tend to follow this same pattern.GitLab isn't portable to Windows at all,for example. For that matter, GitLab isn't even officially supported onmacOS, the BSDs, or uncommon Linuxes! We have many users who regularlybuild and run Fossil on all of these systems.
Fossil and Git promote different development styles because each one wasspecifically designed to support the creator's main softwaredevelopment project:LinusTorvalds designed Git to support development ofthe Linux kernel, andD. Richard Hipp designedFossil to support the development ofSQLite.Both projects must rank high on any objective list of "mostimportant FOSS projects," yet these two projects are almost entirely unlikeone another, so it is natural that the DVCSes created to support theseprojects also differ in many ways.
In the following sections, we will explain how four key differencesbetween the Linux and SQLite software development projects dictated thedesign of each DVCS's low-friction usage path.
When deciding between these two DVCSes, you should ask yourself, "Is myproject more like Linux or more like SQLite?"
Eric S. Raymond's seminal essay-turned-book"TheCathedral and the Bazaar" details the two major developmentorganization styles found inFOSSprojects. As it happens, Linux and SQLite fall on opposite sides of thisdichotomy. Differing development organization styles dictate a differentdesign and low-friction usage path in the tools created to support eachproject.
Git promotes the Linux kernel's bazaar development style, in which aloosely-associated mass of developers contribute their work throughahierarchy of lieutenants who manage and clean up these contributionsfor consideration by Linus Torvalds, who has the power to cherry-pickindividual contributions into his version of the Linux kernel. Gitallows an anonymous developer to rebase and push specific locally-namedprivate branches, so that a Git repo clone often isn't really a clone atall: it may have an arbitrary number of differences relative to therepository it originally cloned from. Git encourages siloed development.Select work in a developer's local repository may remain privateindefinitely.
All of this is exactly what one wants when doing bazaar-styledevelopment.
Fossil's normal mode of operation differs on every one of these points,with the specific designed-in goal of promoting SQLite's cathedraldevelopment model:
Where Git encourages siloed development, Fossil fights against it.Fossil places a lot of emphasis on synchronizing everyone's work and onreporting on the state of the project and the work of its developers, sothat everyone — especially the project leader — can maintain a bettermental picture of what is happening, leading to better situationalawareness.
By contrast, "…forking isat the core of social coding at GitHub". As of January 2022,Github hosts 47 million distinctsoftware projects, most of which were created by forking apreviously-existing project. Since this isroughlytwice the number of developers in the world, it beggars belief thatmost of these forks are still under active development. The vast bulkof these must be abandoned one-off efforts. This is part of the natureof bazaar style development.
You can think about this difference in terms offeedback loop size, which weknow from the mathematics ofcontrol theory todirectly affect the speed at which any system can safely make changes.The larger the feedback loop, the slower the whole system must run inorder to avoid loss of control. The same concept shows up in othercontexts, such as in theOODAloop concept.Committing your changes to private branches in order to delay a publicpush to the parent repo increases the size of your collaborators'control loops, either causing them to slow their work in order to safelyreact to your work, or to over-correct in response to each change.
Each DVCS can be used in the opposite style, but doing so works againsttheir low-friction paths.
The Linux kernel has a far bigger developer community than that ofSQLite: there are thousands and thousands of contributors to Linux, mostof whom do not know each other's names. These thousands are responsiblefor producing roughly 89× more code than is in SQLite. (10.7MLOC vs. 0.12 MLOCaccording toSLOCCount.) The Linuxkernel and its development process were already uncommonly large back in2005 when Git was designed, specifically to support the consequences ofhaving such a large set of developers working on such a large code base.
95% of the code in SQLite comes from just four programmers, and 64% ofit is from the lead developer alone. The SQLite developers know eachother well and interact daily. Fossil was designed for this developmentmodel.
When choosing your DVCS, we think you should ask yourself whether thescale of your software configuration management problems is closer tothose Linus Torvalds designed Git to cope with or whether your work'sscale is closer to that of SQLite, for which D. Richard Hipp designedFossil. Anautomotive airimpact wrench running at 8000 RPM driving an M8 socket-cap bolt at 16cm/s is not the best way to hang a picture on the living room wall.
Fossil works well for projects several times the size of SQLite,such as Tcl, with a repository overtwice the size and with many more core committers.
Both Fossil and Git store history as a directed acyclic graph (DAG)of changes, but Git tends to focus more on individual branches ofthe DAG, whereas Fossil puts more emphasis on the entire DAG.
For example, the default behavior in Git is to only synchronizea single branch, whereas with Fossil the only sync option is tosync the entire DAG. Git commands,GitHub, and GitLab tend to show only a single branch ata time, whereas Fossil usually shows all parallel branches atonce. Git has commands like "rebase" that help keep all relevantchanges on a single branch, whereas Fossil encourages a style ofmany concurrent branches constantly springing into existence,undergoing active development in parallel for a few days or weeks, thenmerging back into the main line and disappearing.
This difference in emphasis arises from the different purposes ofthe two systems. Git focuses on individual branches, because thatis exactly what you want for a highly-distributed bazaar-style projectsuch as Linux. Linus Torvalds does not want to see every check-inby every contributor to Linux: such extreme visibility does not scalewell. Contrast Fossil, which was written for the cathedral-style SQLite projectand its handful of active committers. Seeing allchanges on all branches all at once helps keep the whole teamup-to-date with what everybody else is doing, resulting in a more tightly focused and cohesive implementation.
Parts of this section aredisputedbyJakub A. G..
Because Git commingles the repository data with the initial checkout ofthat repository, the default mode of operation in Git is to stick to thatsingle work/repo tree, even when that's a shortsighted way of working.
Fossil doesn't work that way. A Fossil repository is an SQLite databasefile which is normally stored outside the working checkout directory. You canopen a Fossil repository any number of times intoany number of working directories. A common usage pattern is to have oneworking directory per active working branch, so that switching branchesis done with acd command rather than by checking out thebranches successively in a single working directory.
Fossil does allow you to switch branches within a working checkoutdirectory, and this is also often done. It is simply that there is noinherent penalty to either choice in Fossil as there is in Git. Thestandard advice is to use a switch-in-place workflow in Fossil whenthe disturbance from switching branches is small, and to use multiplecheckouts when you have long-lived working branches that are differentenough that switching in place is disruptive.
While you canuse Git in the Fossil style,Git's default tie between working directory andrepository means the standard method for working with a Git repo is tohave one working directory only. Most Git tutorials teach this style, soit is how most people learn to use Git. Because relatively few peopleuse Git with multiple working directories per repository, there areseveral knownproblems with that way of working, problems which don't happen in Fossil because ofthe clearseparation between a Fossil repository andeach working directory.
This distinction matters because switching branches inside a single working directory loses local contexton each switch.
For instance, in any software project where the runnable program must bebuilt from source files, you invalidate build objects on each switch,artificially increasing the time required to switch versions. Most obviously, thisaffects software written in statically-compiled programming languagessuch as C, Java, and Haskell, but it can even affect programs written indynamic languages like JavaScript. A typicalSPA buildprocess involves several passes:Browserify to convertNode packages so they'll run in a web browser,SASS to CSS translation,transpilation ofTypescript to JavaScript,uglification, etc.Once all that processing work is done for a given inputfile in a given working directory, why re-do that work just to switchversions? If most of the files that differ between versions don't changevery often, you can save substantial time by switching branches withcd rather than swapping versions in-place within a workingcheckout directory.
For another example, you might have an active long-running test grindingaway in a working directory, then get a call from a customer requiringthat you switch to a stable branch to answer questions in terms of theversion that customer is running. You don't want to stop the test inorder to switch your lone working directory to the stable branch.
Disk space is cheap. Having several working directories — each with itsown local state — makes switching versions cheap and fast.
Plus,cd is faster to type thangit checkout orfossilupdate.
Parts of this section aredisputedbyJakub A. G..
Git puts a lot of emphasis on maintaininga "clean" check-in history. Extraneous and experimental branches byindividual developers often never make it into the main repository.Branches may be rebased before being pushed to makeit appear as if development had been linear, or "squashed" to make itappear that multiple commits were made as a single commit.There areother history rewriting mechanisms in Git as well. Git strives to record whatthe development of a project should have looked like had there been nomistakes.
Fossil, in contrast, puts more emphasis on recording exactly what happened,including all of the messy errors, dead-ends, experimental branches, andso forth. One might argue that thismakes the history of a Fossil project "messy," but another point of viewis that this makes the history "accurate." In actual practice, thesuperior reporting tools available in Fossil mean that this incidental messis not a factor.
Like Git, Fossil has anamend command for modifyingprior commits, but unlike in Git, this works not by replacing data inthe repository, but by adding a correction record to the repository thataffects how later Fossil operations present the corrected data. The oldinformation is still there in the repository, it is just overridden fromthe amendment point forward.
Fossil lacks almost every other history rewriting mechanism listed onthe Git documentation page linked above.There is norebase in Fossil, on purpose, thus no way to reorder or copy commitsaround in the commit hash tree. There is no commit squashing, dropping,or interactive patch-based cherry-picking of commit elements in Fossil.There is nothing like Git'sfilter-branch in Fossil.
The lone exception is deleting commits. Fossil has two methods for doingthat, both of which have stringent limitations, on purpose.
The first isshunning. See thatdocument for details, but briefly, you only get mandatory compliancefor shun requests within a single repository. Shun requests do notpropagate automatically between repository clones. A Fossil repositoryadministrator cancooperatively pull another repo's shun requestsacross a sync boundary, so that two admins can get together and agree toshun certain committed artifacts, but a person cannot force their localshun requests into another repo without having admin-level control overthe receiving repo as well. Fossil's shun feature isn't for fixing upeveryday bad commits, it's for dealing with extreme situations: publiccommits of secret material, ticket/wiki/forum spam, law enforcementtakedown demands, etc.
There is also the experimentalpurgecommand, which differs from shunning in ways that aren't especiallyimportant in the context of this document. At a 30000 foot level, youcan think of purging as useful only when you've turned off Fossil'sautosync feature and want to pluck artifacts out of its hash tree beforethey get pushed. In that sense, it's approximately the same asgit rebase -i, drop. However, given that Fossil defaults tohaving autosync enabledfor good reason, the purge commandisn't very useful in practice: once a commit has been pushed intoanother repo, shunning is more useful if you need to delete it fromhistory.
If these accommodations strike you as incoherent with respect toFossil's philosophy of durable, unchanging commits, realize that ifshunning and purging were removed from Fossil, you could still removeartifacts from the repository with SQLDELETE statements; therepository database file is, after all, directly modifiable, beingwritable by your user. Where the Fossil philosophy really takes hold isin making it difficult to violate the integrity of the hash tree.It's somewhat tangential, but the document"Is Fossila Blockchain?" touches on this and related topics.
One commentator characterized Git as recording history according tothe victors, whereas Fossil records history as it actually happened.
One of the things that falls out of Git's default separation of commitfrom push is that there are several Git sub-commands that jump straightto the commit step before a change could possibly be tested. Fossil, bycontrast, makes the equivalent change to the local working check-outonly, requiring a separate check-in step to commit the change. Thisdesign difference falls naturally out of Fossil's default-enabledautosync feature and its philosophy ofnot offering historyrewriting features.
The prime example in Git is rebasing: the change happens to the localrepository immediately if successful, even though you haven't tested thechange yet. It's possible to argue for such a design in a tool like Gitsince it lacks an autosync feature, because you can still test thechange before pushing local changes to the parent repo, but in themeantime you've made a durable change to your local Git repository. Youmust do something drastic likegit reset --hard to revert thatrebase or rewrite history before pushing it if the rebase causes aproblem. If you push your rebased local repo up to the parent withouttesting first, you cannot fix it without violatingthe golden rule of rebasing.
Lesser examples are the Gitmerge,cherry-pick, andrevert commands, all of which apply work from one branch ontoanother, and all of which commit their change to the local repositoryimmediately without giving youan opportunity to test the change first unless you give the--no-commit option. Otherwise, you're back in the same boat:reset the local repository or rewrite history to fix things, then mayberetry.
Fossil cannot sensibly work that way because of its default-enabledautosync feature and its purposeful paucity of commands for modifyingcommits, as discussed inthe prior section.
Instead of jumping straight to the commit step, Fossilapplies the proposed merge to the local working directory only,requiring a separate check-in step before the change is committed to therepository. This gives you a chance to test the change first,either manually or by running your software's automatic tests. (Ideally,both!) Thus, Fossil doesn't need rebase, squashing,reset --hard, or other Git commit mutating mechanisms.
Because Fossil requires an explicit commit for a merge, it has the niceside benefit that it makes you give an explicit commitmessagefor each merge, whereas Git writes that commit message itself by defaultunless you give the optional--edit flag to override it.
We don't look at this difference as a workaround in Fossil for autosync,but instead as a test-first philosophical difference:fossil commit is acommitment. When every commit ispushed to the parent repo by default, it encourages a working style inwhich every commit is tested first. It encourages thinking beforeacting. We believe this is an inherently good thing.
Incidentally, this is a good example of Git's messy command design.These three commands:
$ git merge HASH $ git cherry-pick HASH $ git revert HASH
...are all the same command in Fossil:
$ fossil merge HASH$ fossil merge --cherrypick HASH$ fossil merge --backout HASH
If you think about it, they're all the same function: apply work done onone branch to another. All that changes between these commands is howmuch work gets applied — just one check-in or a whole branch — and themerge direction. This is the sort of thing we mean when we point outthat Fossil's command interface is simpler than Git's: there are fewerconcepts to keep track of in your mental model of Fossil's internaloperation.
Fossil's implementation of the feature is also simpler to describe. Thebrief online help forfossil merge iscurrently 41 lines long, to which you want to add the 600 lines ofthe branching document. The equivalentdocumentation in Git is the aggregation of the man pages for the abovethree commands, which is over 1000 lines, much of it mutually redundant.(e.g. Git's--edit and--no-commit options getdescribed three times, each time differently.) Fossil'sdocumentation is not only more concise, it gives a nice split of briefonline help and full online documentation.
Fossil started out using 160-bit SHA-1 hashes to identify check-ins,just as in Git. That changed in early 2017 when news of theSHAttered attack broke, demonstrating that SHA-1collisions were now practical to create. Two weeks later, the creator ofFossil delivered a new release allowing a clean migration to256-bit SHA-3 withfull backwards compatibility to old SHA-1 basedrepositories.
In October 2019, after the last of the major binarypackage repos offering Fossil upgraded to Fossil 2.x,we switched the default hash mode so thatthe conversion to SHA-3 is fully automatic.This notonly solves the SHAttered problem, it should prevent a reoccurrence ofsimilar problems for the foreseeable future.
Meanwhile, the Git community took until August 2018 to publishtheir first planfor solving the same problem by moving to SHA-256, a variant of theolder SHA-2 algorithm. As ofthis writing in February 2020, that plan hasn't been implemented, as faras this author is aware, but there is nowa competing SHA-256 based plan which requires complete repositoryconversion from SHA-1 to SHA-256, breaking all public hashes in therepo. One way to characterize such a massive upheaval in Git terms is awhole-project rebase, which violates theGolden Rule of Rebasing.
Regardless of the eventual implementation details, we fully expect Gitto move off SHA-1 eventually and for the changes to take years more topercolate through the community.
Almost three years after Fossil solved this problem, theSHAmbles attack was published, furtherweakening the case for continuing to use SHA-1.
The practical impact of attacks like SHAttered and SHAmbles on theGit and Fossil Merkle trees isn't clear, but you want to have your repositoriesmoved over to a stronger hash algorithm before someone figures out howto make use of the weaknesses in the old one. Fossil has had this coveredfor years now, so that the solution is now almost universally deployed.
Many things are lost in making a Git mirror of a Fossil repo due to limitations of Git relative to Fossil. GitHub adds some of these missing features to stock Git, but because they're not part of Git proper,exporting a Fossil repository to GitHub will still not include them; Fossil tickets do not become GitHub issues, for example.
Thefossil-scm.org web site is actually hosted in several parts, so that it is not strictly true that "everything" on it is in the self-hosting Fossil project repo. The web forum is hosted asa separate Fossil repo from themain Fossil self-hosting repo for administration reasons, and the Download page content isn't normally synchronized with a "fossil clone" command unless you add the "-u" option. (See "How the Download Page Works" for details.) Chat history is deliberately not synced as chat messages are intended to be ephemeral. There may also be some purely static elements of the web site served via D. Richard Hipp's own lightweight web server,althttpd, which is configured as a front end to Fossil running in CGI mode on these sites.
That estimate is based on pricing at Digital Ocean in mid-2019: Fossil will run just fine on the smallest instance they offer, at US $5/month, but the closest match to GitLab's minimum requirements among Digital Ocean's offerings currently costs $40/month.
This means you can give up waiting for Fossil to be ported to the PDP-11, but we remain hopeful that someone may eventually port it toz/OS.
"Why is there all this Tcl in and around Fossil?" you may ask. It is because D. Richard Hipp is a long-time Tcl user and contributor. SQLite started out as an embedded database for Tcl specifically. ([Reference]) When he then created Fossil to manage the development of SQLite, it was natural for him to use Tcl-based tools for its scripting, build system, test system, etc. It came full circle in 2011 whenthe Tcl and Tk projects moved from CVS to Fossil.
A minority of the pieces of the Git core software suite are written in other languages, primarily Perl, Python, and Tcl. (e.g.git-send-mail,git-p4, andgitk, respectively.) Although these interpreters are quite portable, they aren't installed by default everywhere, and on some platforms you can't count on them at all. (Not just Windows, but also the BSDs and many other non-Linux platforms.) This expands the dependency footprint of Git considerably. It is why the current Git for Windows distribution is 44.7 MiB but the currentfossil.exe zip file for Windows is 2.24 MiB. Fossil is much smaller despite using a roughly similar amount of high-level scripting code because its interpreters are compact and built into Fossil itself.
Both Fossil and Git supportpatch(1) files — unified diff formatted output — for accepting drive-by contributions, but it's a lossy contribution path for both systems. Unlike Git PRs and Fossil bundles, patch files collapse multiple checkins together, they don't include check-in comments, and they cannot encode changes made above the individual file content layer: you lose branching decisions, tag changes, file renames, and more when using patch files. Thefossil patch command also solves these problems, but it is because it works like a Fossil bundle, only for uncommitted changes; it doesn't use Larry Wall'spatch tool to apply unified diff output to the receiving Fossil checkout.