What this project has had to understand about Fossil's git export and import, beyond Fossil's manual: the points that changed a design or caused a failure. The rest of what it has learned about Fossil is in docs/fossil.md.

Git export and import

Tried with Fossil 2.27 and a scratch git repository, 2026-10-07 (f3bb7b2032):

• fossil git export DIR writes a git repository in DIR/.git and what its next export needs in DIR/.mirror_state/db: mconfig (the main branch, the autopush) and mmark, each check-in's hash beside the git commit it became. It records DIR in the repository's last-git-export-repo setting, and runs again into it given no DIR; --if-mirrored does nothing for a repository with none. It pushes only where --autopush said, a setting the export keeps.
• fossil git status says where the export is, when Fossil last exported, its autopush, without any password its URL holds, and main branch, and N check-ins awaiting export or up-to-date.
• git fast-export --all names a commit by the first ref that reaches it, a tag before a branch: it wrote main's history under refs/tags/v1, so fossil import --git put those check-ins on no branch, with only the newest on main, and tagged every check-in trunk. An import names branches first.
• A plain fossil import --git then fossil git export rewrites every commit, keeping each tree: authors become their e-mail, times move a second, zones are dropped, each message gains a FossilOrigin-Name: line, the check-ins on no branch come back on a branch unknown, and an annotated tag comes back lightweight.
• Seeded, the export keeps the upstream's commits. Export marks from both sides (git fast-export --export-marks, fossil import --git --export-marks), joined on the mark into mmark, and the git repository holding the upstream's objects, make the first export add nothing. A Fossil check-in then exports as a commit whose parent is the upstream's own, and a clone of the upstream fetches it as a fast-forward. Its mconfig key start, the newest exported check-in's Julian day, is what fossil git status counts awaiting check-ins from.
• git fast-export --branches with no tags gives every check-in its branch, and fossil git export leaves refs it does not know as they are, so an upstream's annotated tags stay as they were.
• fossil import --git reads its standard input given no file, so git's fast-export goes straight into it through a pipe and no stream is kept: beagleboard-org's, 3.0 GB packed on GitHub with 527,641 commits, passed 8 GB as a file within ten minutes (tried 2026-10-21; HISTORY.md decision 120).
• fossil import --git writes each check-in's whole manifest, every file of its tree, not a delta manifest, whatever git's commit changed: a November 2018 commit of beagleboard-org, one of 453,383 that each changed one file, lists 10,779. Its cost follows the commits times the tree, not the pack: that upstream, 3.3 GB packed, took 13 h 17 min of CPU and made a 10.6 GB repository, its temporary tables 1.1 GB; there fossil artifact read that November check-in's manifest in 5 min 20 s, the tip's in 16 ms (tried 2026-10-22; HISTORY.md decision 120; docs/backlog.md).
• Its last step is a VACUUM unless given --no-vacuum: SQLite copies the whole repository into a temporary file in its temporary directory (SQLITE_TMPDIR, else /tmp), deleted as it is opened, so only /proc/PID/fd shows it; in a sandbox's /tmp, a tmpfs, it is held in memory. A 180 MB import was the same size after a VACUUM as before, so an import leaves it out (tried 2026-10-21).
• fossil import --git keeps git's branch names, master among them, and a repository with no trunk opens a checkout on its newest check-in, whatever its branch. --refspec refs/heads/main:refs/heads/trunk on the fast-export names the upstream's own branch trunk in Fossil, and the export, its main branch main, names it back.