The enginesiengine The version control system that actually keeps a repository: fossil, git, hg, jj or lore. spicemine hosts them rather than replacing them, so your own tools talk to the real thing and nothing here is a dialect you would have to learn.
A repository has to be kept by something, and spicemine does not keep it itself: it hosts a real engine and gets out of the way. Pick by how you work, not by which is newest - and know that moving later means a fresh clone, not a migration.
Which engine?
Fossil
One file, batteries included
Good forA small group's long-lived project, with its issues, wiki and notes kept in the same single file as the work.
Watch outFew people already know it, and tools that assume git (CI, editor plug-ins, review sites) will not speak it. Large binary files swell that one file.
Git
What everything else assumes
Good forWorking with anyone: every tool, service and collaborator already speaks it.
Watch outLarge binary files are its weak point - it needs an add-on for them - and its commands are famously easy to get wrong.
Mercurial (hg)
Git's manners, without git's edges
Good forTeams that include non-programmers, and very large trees: git's model with a calmer, consistent set of commands.
Watch outA smaller world than git's: fewer hosts, plug-ins and people who already know it.
Jujutsu (jj)
Git's storage, and an undo button
Good forReshaping work before you show it - stacked changes, painless rebases, and an undo for everything - while it stays an ordinary git repository to everyone else.
Watch outYoung and still changing. On this host the timeline shows git commit ids, not jj's own change ids.
Sub (a mirror of something hosted elsewhere)
Somebody else's repository, kept here
Good forKeeping a readable, clonable copy here of a project whose home is somewhere else.
Watch outRead-only: nobody can push to it, and it is only as fresh as its last refresh.
Loreexperimental
The new one, and it shows
Good forGames, film, audio and art: large binary files stored as deduplicated chunks, and working copies that fetch only what you open. An open (MIT) alternative to the commercial servers studios usually pay for.
Watch outBefore 1.0, and experimental here: formats may change, file locks warn rather than block, and lore has no read-only access, so readers read it through these pages or a git mirror. Keep a copy of anything you cannot lose.
Fossil
One file, batteries included
A whole repository is a single SQLite file, and one small binary carries version control, a bug tracker, a wiki, a forum and its own web interface. It was written to run the SQLite project itself, which is to say it was written by people who maintain one codebase for decades and wanted nothing they would have to assemble.
What it suits
Long-lived work by a small group, and anyone who would rather have one thing to back up than six services to keep in sync. If you want issues and notes to live with the work instead of in somebody else's database, this is the one engine here that already does that.
In spicemine
Fully hosted. spicemine authorises every request itself and then hands it to fossil's own CGI, so clone, sync and the timeline all work, and the repository file is what gets backed up.
Status
Ready. Clone, push and browse.
Git
What everything else assumes
The engine the rest of the industry is built around: fast at branching, unmatched in tooling, and awkward in exactly the places you have heard it is. Its model is content-addressed snapshots, which is why a revision names a state and not a diff.
What it suits
Anything that has to interoperate: a team that already knows it, a project with contributors who will not learn a second tool, or work that needs the editor plug-in, the CI runner and the review tool that only exist for git. Large binary files are its weak point - a photographer's archive will outgrow it before a programmer's will.
In spicemine
Fully hosted, in-process: spicemine serves git's smart HTTP protocol itself. Clone and push over HTTPS with a token as the password, and the repository page reads the timeline and the README straight out of the object store.
Status
Ready. Clone, push and browse.
Mercurial (hg)
Git's manners, without git's edges
Mercurial: the same distributed model as git, with a command set that was designed rather than accumulated. Fewer ways to lose work, fewer concepts to hold at once, and a reputation for being the one people stop being frightened of.
What it suits
Mixed teams where not everyone is a programmer, and large trees - it handles very big repositories gracefully, which is part of why Meta and Mozilla stayed with it. A good first choice if the work matters more to you than the tool does.
In spicemine
Hosted through a local hgweb process that spicemine runs and reverse-proxies, after it has authorised the request itself. Clone, push, timeline and README all work.
Status
Ready. Clone, push and browse.
Jujutsu (jj)
Git's storage, and an undo button
Jujutsu: a different set of commands over git's own repositories. There is no staging area and no detached head - your working copy is itself a commit - and every operation is written to a log that `jj undo` can walk back, a rebase included. A change keeps its identity while the commit under it is rewritten, which is how it rebases the descendants for you instead of asking.
What it suits
Anyone who reorganises work before showing it: stacked branches, long review cycles, a commit series that gets rewritten more than once. It reads and writes ordinary git repositories, so the rest of a git team never has to know you chose it.
In spicemine
Hosted as the git repository it is. jj has no server of its own, so `jj git clone` and `jj git push` use the same HTTPS address and the same token as git, and spicemine authorises each request itself before serving it. A second, server-side jj repository over the same storage is what reads the history for this page. The timeline shows git commit ids - the identity a clone, a mirror and a git user all agree on; change ids live on your side for now.
Status
Ready. Clone, push and browse.
Sub (a mirror of something hosted elsewhere)
Somebody else's repository, kept here
A sub is a repository with no history of its own: you give it an address, and this instance keeps a readable, clonable copy of what is there. It is a mirror pointed inward - the opposite of the mirrors on a repository's own page, which serve this instance's history out in another engine's format. Pushing to a sub is refused, because the next refresh would overwrite it.
What it suits
A project whose home is somewhere else and whose readers are here: a dependency you want to keep a copy of, a fossil project you want git and jj users to be able to clone, or a repository on a service you would rather not send your readers to.
In spicemine
Stored as jj - a git repository with a jj repo over it - whatever the upstream speaks, so one copy serves git clients, jj clients, the timeline and the backup. A fossil upstream is cloned with fossil and converted through the same exporter a fossil-to-git mirror uses; a git or jj upstream is fetched by jj. It is read-only by construction and names its upstream on its own page.
Status
Ready. Clone, push and browse.
Lore
The new one, and it shows
Epic Games' open-source (MIT) version control for projects that mix code with large binary assets - games and entertainment, "for developers and artists alike", in its own words. Content is stored as deduplicated chunks, so a multi-gigabyte file is as cheap to version as a page of text, and a working copy fetches only the files you open. Staging, committing, branching and diffing run on your machine; the server is the record. Clients speak gRPC (or QUIC) to a lore server, not the HTTP the other engines use.
What it suits
Small and independent studios making games, film, music or art who would otherwise pay for a commercial centralized server, and creative work in general, where the files are big and binary and a text-oriented engine starts to creak. Its design also takes access seriously: every repository is an isolated partition, and a folder that needs its own audience is meant to become its own repository, linked into the parent. That linking workflow is on lore's roadmap for 2026 and is not usable yet. Until 1.0, pick it for work you could re-create, not for the only copy.
In spicemine
Provisioned, not proxied. spicemine creates the repository on a managed lore server and hands you the address to clone from. The lore client talks to that server, not to these pages. The timeline here is read from the server and shows the main branch only. Since 0.42.0 these pages also list and read its files, and add files (a dropped file, a saved conversation) as one revision, through the server and without fetching the rest of the project.
Status
Experimental, and upstream is before its 1.0. Repository creation, the timeline, browsing files and adding them from these pages work; anyone who writes to the space can clone and push. lore has no read-only access, so readers read through these pages, or clone a git mirror of the project (0.50.0). Do not put anything here that you could not afford to lose.