libfossil

Install install

$ go install github.com/danmestas/libfossil/cmd/libfossil@latest
$ libfossil --help

That is the entire install. The binary is pure-Go, statically linked, and CGo-free — drop it on any Linux/macOS/Windows host with no runtime dependency.

What it is overview

libfossil is a pure-Go reader and writer for Fossil SCM repositories — the SQLite-backed .fossil files used by Fossil. It exposes a Go API for opening repos, reading the timeline, committing, and syncing over HTTP, plus a libfossil CLI driving the same code paths.

No CGo means static binaries that cross-compile cleanly. A GOOS=wasip1 build runs in browsers and edge runtimes. Two SQLite drivers (modernc, ncruces) are swappable depending on whether you want pure-Go ergonomics or a smaller WASM footprint.

• One library, three pluggable axes. Swap the SQLite driver (modernc/ncruces), the sync transport (HTTP/custom), or the observer (OTel/custom) without touching application code.
• Static everywhere. Static binaries cross-compile cleanly. WASM works.
• Embeddable. Drop libfossil.Open into any Go service that needs to read .fossil repos — build pipelines, mirror servers, code-search indexers.

Why you might want it why

Three reasons to reach for libfossil instead of shelling out to the upstream fossil binary or using CGo bindings.

You're embedding Fossil into a Go service. Build pipelines, code-search indexers, mirror servers, and AI-agent tools that read repository history all benefit from a library API instead of subprocess parsing. No exec calls, no version drift between hosts, observable through Go's standard context.Context and OpenTelemetry hooks.

You're shipping to constrained targets. Static binaries cross-compile in seconds; CGo bindings don't. WASM compilation works out of the box. The cost is a slightly slower SQLite (modernc is pure Go); the upside is the binary runs on any target without a build farm.

You want one library, not five subprocesses. Calling fossil over os/exec means re-parsing CLI text on every request. libfossil exposes typed Go values directly.

How it fits together architecture

Repo is the only handle your code touches. Three pluggable axes around it decide how SQLite runs, how sync talks to remotes, and where telemetry goes — swappable without changing application code.

Compared to neighbors comparison

Comparison reflects libfossil's current scope. The upstream Fossil binary remains the reference implementation; libfossil targets the embedding-into-Go-services niche.

What it is not limits

No GUI. Fossil ships an embedded web UI; libfossil does not. If you need it, run the upstream fossil binary alongside.

No hosting (yet). libfossil reads and writes .fossil files; it does not run an HTTP server that serves them to other Fossil clients. Mirroring works as a sync target, not a host.

No magic schema migrations. libfossil tracks the upstream Fossil schema. Breaking format changes upstream require a libfossil update before you can open the new format.

Get going start

$ go install github.com/danmestas/libfossil/cmd/libfossil@latest
$ libfossil --help                            # CLI commands
$ libfossil --version

Walkthrough: /docs/quickstart · Architecture: /docs/architecture · SDK reference: /docs/reference/sdk · Source: github.com/danmestas/libfossil.