Graft

Git-like history, branches, remotes, and snapshot-aware diffs for SQLite-backed projects.

Start with the CLI Use the SQLite extension

Graft is a storage and repository layer for SQLite projects. It keeps SQLite’s normal transaction model, then adds a project-level history model that feels familiar if you know Git: a physical worktree, a .graft/ directory, an index, commits, branches, tags, and named remotes.

The main integration point is still SQLite. Repository operations are exposed as PRAGMA graft_* commands so applications can call them from any language with SQLite bindings. The graft CLI is a thin wrapper around the same semantics and includes an embedded SQLite runner for local testing.

What To Read First

CLI Quickstart Build `graft`, initialize a project, edit data, commit, branch, and diff without loading the extension manually.

SQLite Extension Use repository-mode pragmas from SQLite, Python, Node, Ruby, Swift, or any other SQLite host.

Repository Model Understand worktree, index, HEAD, refs, remotes, and how SQLite files become Graft commits.

Diffs Know the difference between repository diffs, snapshot diffs, row-level diagnostics, commit hashes, and LSNs.

Current Shape

Core owns repository semantics: objects, refs, index, branches, remotes, revision parsing, and merge state.
SQLite extension bridges an open SQLite database to repository mode through a VFS and PRAGMA graft_* commands.
CLI is a developer-friendly wrapper. It also has graft sql, which opens the project database through the embedded Graft VFS so local testing does not require .load.

Graft is still alpha software. The documentation intentionally calls out current sharp edges, especially where low-level storage diagnostics still use internal LSN coordinates.