Prerequisites
You need two tools installed on every machine:| Tool | Minimum Version | Install |
|---|---|---|
| bd (beads CLI) | 0.59.0+ | See Installation |
| Dolt | 2.1.10+ | brew install dolt or dolt install script |
Initial Setup (First Computer)
1. Initialize beads
.beads/ directory with a Dolt database. If the git repo has
an origin remote, bd init also configures a Dolt remote named origin
pointing at that same git URL. Dolt stores issue data under refs/dolt/data,
separate from normal source branches.
2. Create some issues
3. Verify or add a Dolt remote
In a normal git repo withorigin, this should already be configured:
origin during init, point beads at your Git remote for
sync:
4. Push your issues
Existing Projects Without a Dolt Remote
Projects initialized by older versions ofbd init may have a local embedded
Dolt database and a committed .beads/issues.jsonl, but no Dolt remote. Fix
that from the machine whose local database is authoritative:
bd dolt remote add origin ... writes sync.remote to .beads/config.yaml.
Commit and push that config file with your normal git workflow. Other clones can
then run bd bootstrap if their database is missing/stale, or bd dolt pull
when they already have the right database.
Cloning to a New Computer
When you clone a repo that already has beads data on the remote, a standardgit clone does not fetch refs/dolt/data. You need to bootstrap the Dolt database.
Quick path: bd bootstrap
On recent versions of bd,bd bootstrap handles everything automatically:
bd bootstrap auto-detects refs/dolt/data on origin, clones the Dolt database, and configures the remote. Verify with:
bd bootstrap succeeds, you’re done — skip to Day-to-day Sync.
Manual path (if bootstrap fails)
Ifbd bootstrap doesn’t work (older bd versions, unusual remote configs), follow these steps:
Step 1: Confirm the remote has beads data
.beads/ with an empty database. Ignore any warnings about bd bootstrap — we’ll replace the empty database manually.
Step 3: Stop the Dolt server
dolt_database field is your <dbname> (typically the repo name).
dolt clone already set it up.
Step 8: Verify
Day-to-day Sync
Once set up on both machines, sync is two commands:Typical workflow
Important rules
- Always use
bd dolt ...commands — never run rawdoltCLI commands while the Dolt server is running. It causes journal corruption. - Commit before pulling — if you have uncommitted working set changes,
bd dolt pullwill fail with “cannot merge with uncommitted changes”. Runbd dolt commitfirst. - Push before switching machines — unpushed changes only exist locally.
- Do not use JSONL as sync —
.beads/issues.jsonlis an export for viewers and interchange. It is not the source of truth, not a full database backup, and cannot safely reconcile deletes or pruning.
Troubleshooting
”no common ancestor” on push
A stalerefs/dolt/data from a previous database is conflicting. Clear it and retry:
“cannot merge with uncommitted changes” on pull
Commit your working set first:“no store available” on push or commit
This was a bug in bd < 0.59.0. Upgrade bd:bd list shows nothing after clone
The Dolt database wasn’t bootstrapped. Either runbd bootstrap or follow the manual path above.
Stale lock files after crash
.dolt/ directories (including
noms/LOCK). These are Dolt-internal files and removing them will cause
unrecoverable data corruption. Dolt manages these files itself.
”fatal: Unable to read current working directory”
The Dolt server’s working directory no longer exists (common after branch switches). Restart it:See Also
- Sync Concepts — The conceptual model behind this setup (why Dolt is the source of truth, what JSONL is for)
- Quick Start — Getting started with beads
- Dolt Backend for Beads — Dolt backend details, server modes, federation, remote types, and sync modes
- Installation — Installation for all platforms