mirror of
https://github.com/ModernRelay/omnigraph.git
synced 2026-06-15 01:55:13 +02:00
612741b387
Content build-out on top of the Phase 1 topic move. No behavior changes. Splits (existing content relocated, cross-linked): - queries/index.md → mutations/index.md (insert/update/delete + the inserts-vs-deletes rule) and search/index.md (the multi-modal search functions + a hybrid-ranking overview tying nearest/bm25/rrf together). queries/index.md now covers the read shape and points at both. - branching/index.md → branching/time-travel.md (snapshots/time travel) and branching/merge.md (three-way merge + the 7 conflict kinds, verified against error.rs MergeConflictKind). New pages (written from the code, user-facing): - quickstart.md — init → load → query → branch, with verified CLI flags. - concepts/index.md — what OmniGraph is + the L1/L2 (Lance/OmniGraph) framing. Expanded operations/audit.md from a 7-line struct dump into a real actor-tracking page (server token-resolved vs CLI --as chain; reading the trail; the omnigraph:recovery reserved actor). Index wiring: docs/user/index.md and AGENTS.md's topic table link every new page; also normalized AGENTS.md's docs/user link display text to match the Phase 1 retargeted paths. Verified: zero broken .md links; check-agents-md.sh green (57 links, 54 docs). Deferred to Phase 3: de-dev polish (grammar paths, IR internals still in queries/branching), guides/, and a possible reference/config.md split (the config schema is already coherent in cli/reference.md). Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
47 lines
2 KiB
Markdown
47 lines
2 KiB
Markdown
# Merging Branches
|
|
|
|
Merging integrates the changes on one branch into another. OmniGraph merges are
|
|
**three-way and row-level**: it compares both branches against their common
|
|
ancestor and merges each node/edge table row by row, then publishes the result as
|
|
**one atomic commit** across the whole graph.
|
|
|
|
```bash
|
|
omnigraph branch merge review/2026-04-25 --into main s3://bucket/graph.omni
|
|
```
|
|
|
|
`branch merge <source> [--into <target>]` merges `<source>` into `<target>`
|
|
(default `main`).
|
|
|
|
## Outcomes
|
|
|
|
A merge resolves to one of three outcomes:
|
|
|
|
- **Already up to date** — the target already contains every change on the source;
|
|
nothing to do.
|
|
- **Fast-forward** — the target has no changes the source lacks, so the target
|
|
simply advances to the source.
|
|
- **Merged** — both sides diverged; a new merge commit is created with two parents.
|
|
|
|
## Conflicts
|
|
|
|
When both branches changed the same data incompatibly, the merge fails with a
|
|
structured list of conflicts (the HTTP server returns `409` with a
|
|
`merge_conflicts[]` array). No partial result is published — the merge is
|
|
all-or-nothing. The conflict kinds are:
|
|
|
|
| Kind | Meaning |
|
|
|---|---|
|
|
| `DivergentInsert` | The same id was inserted on both branches. |
|
|
| `DivergentUpdate` | The same row was updated differently on both branches. |
|
|
| `DeleteVsUpdate` | One side deleted a row the other side updated. |
|
|
| `OrphanEdge` | An edge references a node the other side deleted. |
|
|
| `UniqueViolation` | The merged result would violate a unique constraint. |
|
|
| `CardinalityViolation` | The merged result would violate an edge cardinality constraint. |
|
|
| `ValueConstraintViolation` | The merged result would violate a value constraint (enum/range). |
|
|
|
|
Each conflict carries the table, the row id (when applicable), the kind, and a
|
|
message. Resolve conflicts by reconciling the two branches — typically by making
|
|
the conflicting change on one side and re-merging.
|
|
|
|
See [branches & commits](index.md) for the branch and commit-DAG model, and
|
|
[changes](changes.md) for diffing two branches before you merge.
|