Questions, answered straight
The things people ask before putting their issue tracker inside git. Everything here reflects how grite actually works — see how it works and the comparisons for detail.
+ Does grite need a server or database?
No. grite stores issues inside your git repository, in a ref named refs/grite/wal. There is no server to run and no database to provision. The only runtime dependency is git 2.38 or later. An optional grite-daemon exists purely to keep queries fast, and the CLI works fine without it.
+ How are merge conflicts avoided?
grite records issue changes as an append-only event log and merges concurrent edits with CRDT (conflict-free replicated data type) rules — last-write-wins on scalar fields and commutative-set semantics on labels and dependencies. Any two valid logs merge to the same result regardless of order, so you never get a merge conflict on issues.
+ What exactly is stored in git?
An append-only, CBOR-encoded event log under refs/grite/wal. Each event is a single issue mutation (create, label, assign, close), content-addressed by a hash of its payload, and optionally signed with an Ed25519 key. Your working tree is never touched — issues do not appear as files in your source.
+ Will grite bloat my repository?
Events are compact CBOR records stored in a dedicated ref, not in your working tree, so they do not clutter code review. Because the data lives in git's object store like any other ref, it benefits from git's normal packing and compression.
+ What does signing give me?
Optional Ed25519 signatures bind each event to a per-actor key, providing non-repudiable provenance — cryptographic proof of who made each change. Combined with the content-addressed, append-only log, this makes the history tamper-evident: any modification breaks the hash chain and is detectable.
+ Can AI coding agents use grite?
Yes — grite is built for AI coding agents as first-class issue authors alongside humans. Agents open, update, and close issues through the CLI, using the task graph as durable memory that survives across sessions. Because merges are conflict-free, multiple agents can work the same graph in parallel. See the AI coding agents use case for the full pattern.
+ How do I install it, and on which platforms?
grite is distributed via Cargo, npm (grite-cli), pip (grite-cli), gem (grite-cli), Homebrew, and Chocolatey, so you can install it from whatever package manager you already use. It ships as a single CLI plus an optional background daemon.
+ Does grite replace GitHub Issues, Linear, or Beads?
It depends on what you need. grite is the offline-first, repo-local task graph with CRDT merge and no server. Many teams keep GitHub Issues for public inbound reports and use grite for the internal graph. Against Linear it is a different architecture — issues in git, no accounts. Against Beads it stores the same kind of issues as pure git refs instead of an embedded database. See the comparisons for honest, side-by-side detail.
+ Is grite open source?
Yes. grite is MIT licensed and built by Neul Labs, with source on GitHub. It is composed from well-understood primitives — git refs, CRDTs, CBOR, Ed25519 — rather than novel ones.