Merge Conflicts
Lob is a separate, tensor-native version-control system that Tensormorph anchors to - it is not bundled, and Lob's own branch/merge model is not yet finalized. This page explains what a weight-space conflict is and the shape the resolution problem takes, drawing on git/GitHub's conflict model as the closest existing precedent. Treat the interaction flow described below as a design direction, not shipped UI.
How Tensormorph anchors to Lob
Tensormorph doesn't store weight history itself. Instead, a loaded checkpoint carries a commit pin - a reference to the Lob commit it was materialized from - plus a content hash. If the underlying Lob history moves past that pin, Tensormorph detects the mismatch (a stale-note) and surfaces it, rather than silently comparing you against out-of-date history. Reviewing a proposed weight change from inside Tensormorph is referred to as reviewing a weight-space pull request: a Lob-side object that Tensormorph can load, diff, and annotate, even though Tensormorph itself doesn't perform the merge.
What counts as a conflict
Unlike a text-based VCS, "the same region" isn't a line number - it's a tile address in a tensor. By analogy with git's own line-level-vs-structural split, a weight-space conflict is worth distinguishing along the same two axes:
- Numerically resolvable conflicts - two branches changed the same tile or region by a small, distinct amount (two separate quantization passes, or two morph branches that both nudged the same attention head). In principle these could be resolved by a numeric rule - keep one side, or blend them - without touching the rest of the tensor.
- Structural conflicts - the branches disagree on something a numeric rule can't paper over: incompatible shapes, a layer added on one side and removed on the other, or a dtype change only one branch made. These need a human decision about which architecture is correct, not an averaging function.
Whether two changed regions actually conflict is a semantic-diff question, not a byte-for-byte one - two branches that touch the same tile but converge on the same value are not a conflict.
What resolution could look like
GitHub's in-browser conflict editor - pick a side, or write something new, mark resolved, repeat per file - is the closest existing interaction pattern for the resolvable half of this problem, and it transplants reasonably well:
- Open the weight-space pull request and inspect the flagged tensors; each conflicting region is highlighted on a heatmap of both sides' values.
- For a numerically resolvable region, choose a resolution: keep one side's values, or blend them (matching whatever interpolation the originating morph used).
- For a structural conflict, no in-app resolution applies - the underlying change needs to be re-authored against a common base, which happens on the Lob side, outside Tensormorph.
What's genuinely undecided - and therefore not documented as fact here - is whether steps 1–2 ship as in-app actions that write back to Lob, or whether Tensormorph's role stays read-only (surface the conflict, hand off resolution to a Lob-native tool). Don't build against a specific UI for this until Lob's merge model is finalized.
Related resources
- Weight Diff - how a numeric diff between two commits is rendered, independent of whether it's conflicting.
- Model Interpolation - the interpolation math referenced by the "blend" resolution above.
- Model Diff - the semantic-diff machinery used to decide whether a region actually conflicts.