Semantics & limitations

Content merge is line-level

threeWayMerge’s content merge (used only for files both sides changed from the merge base) is node-diff3’s line-level diff3 — the same algorithm git’s default merge driver uses, but with no rename detection and no recursive merge of criss-cross histories (the first merge base git.findMergeBase returns is used). See Three-way merge for the full decision tree.

Binary files conflict instead of merging

A file with a NUL byte in any of the three versions is never line-merged — both sides changing it differently is reported as a conflict.

The parsed-object and repo caches are independent utilities

Neither createParsedObjectCache nor getRepoCache/invalidateRepoCache is required by threeWayMerge — they’re general-purpose helpers extracted alongside the merge logic because the same production service needed them, not because the merge implementation depends on them. Use whichever pieces you need; nothing here requires importing all of them together.

No worktree operations at all

git-edge only ever reads/writes the object graph (trees, blobs, commits) and refs — there’s no checkout, add, or status here, and no code path that expects a real filesystem checkout to exist. If you need those, that’s isomorphic-git’s own worktree API against a real (or hydrated-to-/tmp) fs, outside git-edge’s scope entirely.

Caution

threeWayMerge writes directly to refs (git.writeRef with force: true) and to the object store — it doesn’t serialize concurrent calls against the same repo. Concurrent merges/pushes to the same targetRef need external coordination (a per-repo lock or single-writer queue); this package doesn’t provide one.