Comparison
kal vs git, with both tools running
Every panel below is real output from both tools on the same repository at the same moment. git is excellent at what it was built for — this page is about the five questions it was never designed to answer.
The whole difference, in one picture
A git commit records a tree, a parent, an author string and a free-text message. A kal snapshot records those and the two fields that turn history into knowledge: why the change was made, and whether a human or a model made it.
Five questions, both tools
01“Why does this retry loop exist?”
Six months later, someone needs to change this code and has to know what it was protecting against.
git
$ git log --oneline a144cf5 clone work 9fc67cf merge feature f4825f0 friendlier greeting 49f767b feature docs 94c326b checkpoint
You get the what. The reason lives in a pull request, a Slack
thread, or somebody's memory — and you have to go find whichever it is.
kal
$ kal why app.py provenance of app.py (newest first): snap 6337fc916cdc checkpoint when 2026-07-26 23:29:51 author dev [human] intent automatic work-in-progress checkpoint files 1 modified snap e20d721baa15 add retry helper when 2026-07-26 23:29:50 author claude-code [ai:claude-opus-5] intent the IdP rate-limits bursts of logins files 1 modified snap 92f15ff0e493 scaffold service when 2026-07-26 23:29:50 author dev [human] intent starting the payments service files 2 added
The reason is the data. Every snapshot that touched the file,
each carrying the intent written at the moment the change was made.
02“Did a person write this, or a model?”
When agents commit alongside humans, review priority and accountability depend on the answer.
git
$ git blame app.py ^54b5628 (dev 2026-07-27 1) def hello(): f4825f0e (dev 2026-07-27 2) return 'hello!' fa1a936f (claude-code 2026-07-27 3) fa1a936f (claude-code 2026-07-27 4) def retry(n=3): fa1a936f (claude-code 2026-07-27 5) return n 94c326bd (dev 2026-07-27 6) # tuned
A name and a date. git has one author field, a free string —
an agent looks exactly like a colleague, and the model behind it is unrecorded.
kal
$ kal blame app.py 92f15ff0 dev [hum] 1| def hello(): 92f15ff0 dev [hum] 2| return 'hi' e20d721b claude-code [ai] 3| e20d721b claude-code [ai] 4| def retry(n=3): e20d721b claude-code [ai] 5| return n 6337fc91 dev [hum] 6| # tuned 6 lines: 3 AI-written (50%), 3 human-written
Species, per line. Authorship is structured — human or AI, which
model, which session — so blame ends with an actual human/AI split.
03“I just destroyed an hour of work.”
The universal experience. What matters is how many decisions stand between you and recovery.
git
$ git reflog a144cf5 HEAD@{0}: reset: moving to HEAD a144cf5 HEAD@{1}: a144cf5 HEAD@{2}:
Recovery is a skill. reflog covers commits — but not a botched
merge resolution, a stash you dropped, or a branch deleted before it was pushed. You must know
which tool applies before you can use it.
kal
$ kal undo undid operation #12 (tag: v1.0 at 705455e3468b) refs restored to their prior state; commits are retained (undo is undoable) worktree files were left untouched — add --files to also reset them, or run `kal restore HEAD` yourself
Recovery is one word. Every operation is journalled with its
before-and-after state, so undo reverses any of them — and undo is itself undoable.
04“Was this change ever actually verified?”
Especially when the commit came from an autonomous agent at 3am.
git
$ git show --stat HEAD a144cf5 dev <[email protected]> Mon Jul 27 06:29:57 2026 +0000 clone work
Ask another system. The commit knows nothing about tests. You
go to CI, match the SHA, and hope the run wasn't garbage-collected.
kal
$ kal verify "pytest" verification PASSED — stamped on 6337fc916cdc trust tier of HEAD is now: human-authored
The result rides on the snapshot. AI work climbs a trust ladder
— unverified, tested, approved — and
kal stats turns those stamps into per-model
scorecards.05“Didn't we try this before?”
The most expensive question in software, and the one both humans and agents ask least.
git
$ git branch -d ssr-experiment Deleted branch ssr-experiment (was 4a91c02). $ git log --all --grep "ssr" (no results — the reason it failed was never written down)
The lesson evaporates. The branch is recoverable for a while;
why it was abandoned never existed as data in the first place.
kal
$ kal archive ssr-experiment -r "SSR doubled p95 latency" archived feature at 50df8b82762d reason preserved: server-side rendering doubled p95 latency abandoned approaches (negative knowledge): feature (50df8b82762d, 2026-07-26 23:29:54) reason: server-side rendering doubled p95 latency
Failure becomes memory. Archiving requires a reason, and that
reason surfaces in
kal ask and in the briefing every AI agent reads — so nobody
walks the same dead end twice.The short version
| Can you ask it… | git | kal |
|---|---|---|
| What changed, when, by whom (a name) | yes | yes |
| Branch, merge, tag, bisect, remotes | yes | yes |
| Why a change was made | convention only | structured field |
| Human or AI — and which model | no | per line |
| Undo any operation | reflog, partial | all of them |
| Did tests pass on this commit | external CI | on the snapshot |
| Which model is most reliable here | no | kal stats |
| Why an approach was abandoned | no | kal archive |
| Brief an LLM about this repo | no | kal context |
| Serve history as agent tools | no | kal mcp |
| Ecosystem, hosting, 20 years of tooling | unmatched | via the git bridge |
Where git is still the right answer
Worth saying plainly, because a comparison that claims to win everywhere isn't worth reading:
- Ecosystem. GitHub, GitLab, code review, CI, IDE integrations, twenty years of Stack Overflow answers. kal doesn't replace any of it — it mirrors into git precisely so you keep it.
- Scale and maturity. git has been hardened on the Linux kernel for two decades. kal is a young project: no packfiles yet, and its network protocol is deliberately simple.
- Team familiarity. Everyone already knows git. kal's answer isn't retraining — it's running alongside, so only the people who want the extra layer have to learn anything.
- Submodules, worktrees, partial clone, LFS. Specialised git features kal simply doesn't have.
The honest framing: kal is not a git replacement. It is the
layer git never had — intent, provenance, trust and memory — sitting on top of a git-compatible core,
so adopting it costs you nothing you already rely on.
Try it in sixty seconds, without leaving git
Run this inside any existing git repository. Nothing is rewritten; your .git is untouched
until you explicitly sync.
kal init # coexists with .git kal snap -m "first snapshot" -i "trying kal on this repo" kal why <a-file-you-know> # the question git can't answer kal undo # and nothing is ever lost
If it isn't for you, delete the .kal directory and everything is exactly as it was.