Skip to content

Merge driver evaluation: data, figures, and a README that leads with them - #36

Open
jesusvilela wants to merge 1 commit into
mainfrom
merge-driver-eval
Open

jesusvilela wants to merge 1 commit into
mainfrom
merge-driver-eval

Conversation

@jesusvilela

Copy link
Copy Markdown
Owner

Adds the experiment behind the merge driver as versioned, reproducible evidence, and gives the README a sharper opening built on it.

What's in it

  • experiments/merge_driver/: four experiments plus a dependency-free SVG renderer. Every merge runs through real Git with the driver installed, and is judged by one test: are the committed .semantic/ artifacts byte for byte what aigit chunk would produce?
  • docs/evals/results/2026-10-15-merge-driver/:
    • trial-level CSV and JSON, recording commit, Git, Python and platform
    • a report labelled exploratory under the evaluation program's rules, with method, table views, threats to validity and reproduction steps
    • light and dark figures
  • tests/test_experiment_plots.py: fails if a figure drifts from its data.
  • make merge-driver-eval: reruns everything, in about ten minutes.

Results

Experiment Result
150 replayed concurrent changes × merge / rebase / cherry-pick text merge: 40 needless .semantic/ stops per operation; driver: 0. The same 25 genuine source conflicts in both; 0 stale anywhere
git merge-file vs ort, 400 random merges 8 disagree, 2 both clean with different text (the reason the driver runs ort itself)
32-scenario corner-case sweep 32/32 as expected, 0 stale
Cost, 10–200 files changed on both sides batched 2.6× faster than per-file at 100–200 files; still linear (~35 ms per contested file)

README

It now opens with a "Merges that don't fight you" section: the headline tiles, the replay chart, three plain claims linked to the report, and a badge. It also adds install-merge-driver to the quick start and a merging row to the feature table. Figures use <picture> to switch between light and dark.

Colours were checked with a palette validator rather than by eye. Green beside red failed colour-vision separation (ΔE 4.1), so outcomes use blue, amber and red, always with text labels and a table view.

🤖 Generated with Claude Code

…h it

Four reproducible experiments under experiments/merge_driver/, each through
real Git with the driver installed, judged by one test -- are the committed
.semantic/ artifacts byte for byte what a rebuild produces?

- replay: 150 concurrent change pairs on this repository via merge, rebase and
  cherry-pick. Text merge: 40 needless .semantic/ stops per operation; driver:
  0, with the same 25 genuine source conflicts; 0 stale anywhere.
- algorithms: git merge-file vs ort disagree on 8 of 400 random merges, 2 of
  them both clean with different text.
- sweep: 32 Git operations and corner cases, all as expected, none stale.
- scaling: batched ort merge 2.6x faster than per-file at 100-200 files,
  still linear (~35 ms per contested file).

Trial-level CSV and JSON (with commit, Git, Python, platform) live in
docs/evals/results/2026-10-15-merge-driver/, with a report labelled
exploratory per the evaluation program, and light/dark SVG figures rendered
from the data by a dependency-free script; a test keeps figures and data in
sync. Colours were checked with the palette validator: green beside red
failed colour-vision separation, so outcomes use blue / amber / red.
`make merge-driver-eval` reproduces everything.

The README opens with the results and the figures, and adds the driver to
the quick start and the feature table.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant