Git won, and it is still worth knowing what the alternatives do better, because several of them fix problems Git users have simply learned to tolerate.
Content-addressed storage, cheap local branching, and a data model where every clone is a full backup. Committing, branching and diffing are local and instant. The ecosystem is unmatched — every CI system, editor and hosting platform assumes Git. Any comparison has to start by acknowledging that switching costs are enormous and mostly not technical.
The command-line interface is famously inconsistent, because it exposes plumbing and porcelain through the same namespace. git checkout did three unrelated things until switch and restore split them apart in 2.23, and most documentation still teaches the old form. The index (staging area) is a genuinely useful concept explained badly. And recovering from a bad rebase requires knowing that git reflog exists, which is not discoverable.
Jujutsu uses Git repositories as its backend, so you can adopt it on an existing project without migrating anything and your colleagues need not know. The model differences are substantial: there is no staging area (the working copy is itself a commit, updated automatically), every operation is undoable via jj undo because the operation log records repository state rather than just commits, and conflicts are recorded in commits rather than blocking you — you can rebase a stack, leave conflicts in place, and resolve them later in any order.
In practice that means the rebase-a-long-stack workflow, which in Git means a chain of conflict resolutions you cannot pause, becomes routine. If you frequently maintain stacked branches, this is the one worth an afternoon of evaluation.
Mercurial's command set is more orthogonal than Git's and its default behaviours are safer — history is immutable unless you explicitly enable mutation extensions. Revsets, its query language for selecting commits, is more expressive than anything Git offers natively. It remains in use at very large organisations, but the hosting and tooling ecosystem around it has thinned considerably, which is the practical blocker for new projects.
Game and film studios use centralised version control for a concrete reason: Git stores every version of every file in every clone, so a repository with thousands of multi-megabyte binary assets becomes unusable. Perforce keeps history server-side, supports file locking (which is the correct answer for assets that cannot be merged), and handles workspaces of hundreds of gigabytes. Git LFS papers over this by storing pointers and fetching blobs on demand, but it adds its own operational complexity and does not solve the locking problem.
Sapling works against Git repositories and focuses on making very large monorepos usable, with lazy history fetching so a clone does not require downloading everything. Its stacked-commit workflow and interactive UI are the draw. Realistically it is aimed at organisations with monorepo-scale problems rather than at typical projects.
git switch -c feature # clearer than checkout -b
git restore --staged file # unstage without the checkout confusion
git reflog # every HEAD position for 90 days - the undo button
git rebase -i --autosquash # with commits made via `git commit --fixup=<sha>`
git bisect start / good / bad # binary search a regression
git worktree add ../hotfix main # second checkout, no stashing
git maintenance start # background gc, commit-graph, prefetchreflog and worktree are the two that most change day-to-day experience. Worktrees remove the entire stash-and-switch ritual when an urgent fix arrives mid-feature.
Stay on Git for anything involving other people or existing infrastructure. Add jj on top if you rebase stacked work often — it costs nothing to try because the repository stays a Git repository. Use Perforce or equivalent if your assets are large binaries. And if the real complaint is the interface rather than the model, a good client — lazygit, tig, or your editor's integration — solves more of it than a migration would.