lit is a local execution VCS for autonomous coding workflows on one machine.
It is local-only, offline-first, and intentionally narrower than Git. Repository data lives inside a deterministic .lit/ folder, and once lit is installed it does not depend on remotes, cloud sync, accounts, or a background service.
- Core local workflow:
init,add,commit,log,status,diff,restore,checkout,branch,merge, andrebase. - Safety and workflow control:
checkpoint,rollback,verify,lineage,artifact,gc,doctor, andexport. - Optional desktop GUI:
lit-guiwhen installed with theguiextra. - Machine-readable output: many automation-oriented commands support
--json.
- No
push,pull,fetch, orclone. - No hosted collaboration model.
- No login, token, or permissions system.
- One repository lives inside one working tree on one computer.
exportis a compatibility bridge, not Git parity.
lit requires Python 3.11+.
The recommended workflow is an editable install into a virtual environment. This installs the lit command (a console script) into that environment, so you can run lit ... once the environment is active.
macOS/Linux:
python -m venv .venv
source .venv/bin/activateWindows PowerShell:
python -m venv .venv
.\.venv\Scripts\Activate.ps1If activation is blocked by your PowerShell execution policy, run:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypasspython -m pip install -e .You can now run either:
lit --help
python -m lit --helppython -m lit is the no-PATH fallback and always runs lit using the current Python interpreter.
If you want a regular non-editable install from a checkout instead, use:
python -m pip install .From a repository checkout (editable install):
python -m pip install -e ".[gui]"From PyPI:
python -m pip install "jakal-lit[gui]"Launch the app with:
lit-guiIf lit-gui is not on your PATH, you can launch the same app with:
python -m lit_gui.appIf you want to produce installable artifacts for another environment:
python -m pip install build
python -m buildThis creates files under dist/, for example:
dist/jakal_lit-1.0.0-py3-none-any.whl
dist/jakal_lit-1.0.0.tar.gz
Install from the wheel with:
python -m pip install dist/jakal_lit-1.0.0-py3-none-any.whlIf lit is not found after installing, it usually means you are running a different Python environment than the one you installed into (for example: a different venv, or no venv). Use python -m lit ... to avoid PATH issues, and prefer python -m pip ... so you install into the same interpreter you are running.
The PyPI distribution name is jakal-lit.
Install commands for published releases are:
python -m pip install jakal-lit
python -m pip install "jakal-lit[gui]"The installed commands are still lit and lit-gui.
mkdir demo-project
cd demo-project
lit initExpected output:
Initialized empty lit repository in /path/to/demo-project/.lit
You can also choose the initial branch name:
lit init --branch trunkRe-running lit init in the same folder keeps the repository and prints a reinitialization message.
lit init [path]initializes a repository in the target folder.lit addstages files or directories.lit commit -m <message>creates a revision from the index.lit logshows commit history.lit statussummarizes the working tree.lit diffshows changes against the last commit.lit restorerestores tracked files from a revision without movingHEAD.lit checkoutswitches the working tree to a branch or detached revision.lit branchlists branches or creates a new local branch.lit mergemerges another local revision into the current branch.lit rebaserebases the current branch onto another local revision.
lit checkpoint create|list|show|latestrecords safe boundaries for rollback, review, and lineage work.lit rollbackrestores the working tree to the latest safe checkpoint or a selected checkpoint.lit verify run|statusrecords or inspects verification results for a revision, checkpoint, or lineage head.lit lineage list|show|create|switch|promote|discardmanages isolated lineages for parallel local work.lit lineage workspace materialize|create|attach|list|gcmanages materialized workspace records.lit artifact list|show|link|usageinspects artifact manifests and ownership links.lit gcinspects or collects reclaimable global artifact objects.lit doctorinspects repository health, locks, and unfinished transactions.lit exportbuilds a Git-facing export plan for compatibility workflows.
Many of these commands also support --json and are intended to expose the same canonical repository snapshot and blockage diagnostics that the GUI uses.
This is the everyday local flow the tool is built around:
lit initto create the repository.lit addto stage changes.lit commit -m "message"to save a checkpoint.lit branch feature-nameto create a side branch.lit checkout feature-nameto switch to it.lit merge feature-nameorlit rebase mainto bring work back together locally.lit restore <path>to discard a local file change.
After lit init, the repository contains:
.lit/
HEAD
config.json
index.json
objects/
blobs/
commits/
trees/
refs/
heads/
tags/
checkpoints/
safe/
state/
merge.json
rebase.json
v1/
revisions/
checkpoints/
lineages/
verifications/
artifacts/
workspaces/
operations/
journals/
locks/
Notable details:
config.jsonstoresdefault_branchandschema_version..lit/config.jsonis also the explicit policy surface for verification, checkpoint, artifact, lineage, and resumable operation defaults.HEADpoints torefs/heads/<branch>until you detach it to a revision.- Object identifiers are SHA-256 hashes of raw bytes.
- The richer
v1/records cover revisions, checkpoints, lineages, verifications, artifacts, workspaces, operations, journals, and locks.
lit loads machine-facing policy from .lit/config.json. The current policy groups are:
verification: default definition name and command, cache behavior, and whether verification is required before commit.checkpoints: safe-by-default behavior, approval requirements, and auto-pinning for safe checkpoints.artifacts: artifact storage location and rollback preservation behavior.lineage: default base checkpoint strategy, owned-path enforcement, overlap allowlists, and affected-lineage scope defaults.operations: whether merge/rebase resume is allowed, how safe rollback targets are chosen, and whether blockage reasons are exposed.
These settings are consumed through src/lit/config.py and surfaced through the shared backend service instead of being inferred separately by CLI and GUI callers.
The current v1 structure is intentionally split across a few boundaries:
src/lit/domain.pydefines the canonical records for revisions, checkpoints, lineages, verifications, resumable operations, and repository snapshots.src/lit/backend_api.pyis the shared service boundary for CLI, GUI, and automation-oriented JSON surfaces.src/lit/workflows.pyowns merge, rebase, checkpoint, rollback, verification, and resume/abort orchestration.src/lit/repository.pyremains the storage and mutation engine under that service layer.src/lit_gui/session.pywraps the same backend service rather than shaping repository state independently.
If you are adding features, prefer extending these shared contracts and service paths instead of inventing CLI-only or GUI-only state models.
- Run
lit doctor --jsonwhen automation needs a machine-readable reason for why work is blocked. - Active merge and rebase state include resumable operation metadata, conflict paths, and the current safe rollback target.
lit rollbackuses the configured safe checkpoint preference, so the default recovery target can be lineage-scoped or repository-wide by policy.- Use
lit checkpoint create --jsonbefore high-risk changes when you want an explicit rollback boundary that external orchestration can record.
The repository also includes a simple static site in website/.
- Open
website/index.htmldirectly in a browser. - Or serve it locally with
python -m http.serverand open the URL it prints. - No build step, package manager, or framework is required.
Current limits:
litis still a local-first tool, not a hosted collaboration platform.- There is no remote repository workflow.
- Some compatibility surfaces, like
export, are bridges rather than full Git parity. - GUI support is optional and requires the
guiextra.
Non-goals:
- Hosted sync or remote collaboration
- Accounts, authentication, or permissions infrastructure
- Background daemons or heavy server-side services
Run the test suite with:
python -m pytestRun the supported multi-version matrix with:
python -m pip install -e ".[dev]"
python -m toxtox targets Python 3.11, 3.12, 3.13, plus a packaging check environment. Missing local interpreters are skipped so one machine can still exercise the subset it has installed.
Release and publish steps are documented in docs/releasing.md.