git-edge
High-level edge-compatible git operations on top of isomorphic-git — an object-level three-way merge that never needs a worktree, a parsed-object cache, and per-repo packfile-cache management.
isomorphic-git's own git.merge needs a worktree — a real (or hydrated-to-/tmp)
checkout to run its merge driver against. That's a problem for a bare repo living
entirely in object storage with no durable disk: merging would mean materializing
the whole tree locally first. git-edge's threeWayMerge works directly on the
object graph — trees, blobs, commits — no checkout required, safe to run inside a
Lambda, Worker, or Edge function that only ever sees { fs, gitdir }.
Extracted from the same production git-hosting service as
git-fs-s3 — the two
compose (see Getting started): both work on
isomorphic-git's { fs, gitdir, cache? } shape, and threeWayMerge stores
its objects through git-fs-s3's withPackedWrites.
What's in the package
threeWayMergeThe object-level merge itself — no worktree, no disk, no checkout.
createParsedObjectCacheA generic LRU for parsed values (rendered commit lists, resolved merge bases) keyed however you like.
getRepoCache / invalidateRepoCachePer-repo isomorphic-git packfile cache management.
Why this shape
No worktree, ever
Merges run entirely against the object graph — read trees, diff paths,
write blobs and a tree, write the commit. No checkout, no /tmp, no
cleanup.
Edge-compatible
No node:* imports anywhere in src/. Runs on Cloudflare Workers,
Vercel Edge, Deno Deploy, and Node identically.
Composes with git-fs-s3
Pass in any isomorphic-git-compatible fs — plain node:fs, or
git-fs-s3's S3/R2-backed one. Neither package imports
the other.
Production-tested
Extracted from the same git-hosting service's merge logic — the fast-forward shortcut and the object-level tree merge exist because real traffic needed them.