MergeMate — Submission Writeup

Inspiration

Every developer has hit the same wall: git stops mid-merge, drops raw <<<<<<< ======= >>>>>>> markers into a file, and offers nothing else. No explanation of why two branches collided, no help deciding which change to keep, no sense of what the intended behavior actually was. You're left reconstructing two people's intentions from scratch, usually under time pressure.

That problem gets sharper for developers without constant access to a senior engineer to ask, without a stable low-cost connection to lean on a cloud AI assistant, or without hardware that can run a large model. We wanted to build something that helps with this exact moment — and does it entirely on-device, so it works for someone on a modest laptop with unreliable internet just as well as it works for us.

What it does

MergeMate is an offline, CPU-only assistant that resolves git merge conflicts and explains its reasoning — grounded in real evidence pulled from your own codebase, not guesses.

Point it at a conflicted file:

mergemate resolve pricing.py

Before asking the model anything, MergeMate searches the rest of your project for tests and call sites relevant to the conflicting code — the same thing a developer does before resolving a conflict by hand. It then produces a resolution with an explicit confidence level (HIGH / MEDIUM / LOW) and a plain-language explanation of what each side changed, why they collided, and what evidence informed the fix. LOW-confidence resolutions are never silently applied — MergeMate defers to a human instead of guessing confidently and being wrong.

It runs entirely offline, in under 3.5GB of RAM, on CPU — no API key, no internet connection required after the model is downloaded once.

How we built it

The core is Qwen2.5-Coder-3B-Instruct, quantized to GGUF Q4_K_M and run through llama.cpp — chosen for its code-specific training and small enough footprint to comfortably fit the challenge's RAM budget with real headroom to spare.

The pipeline has five pieces:

conflict_extractor.py parses raw conflict markers into structured data (both sides' code plus surrounding context).
context_retriever.py is the retrieval half of the design — it searches the rest of the repository for tests and usages relevant to the conflict. For Python, it uses the ast module for structural, not just textual, identifier extraction (this also catches function calls, not just definitions — verified directly with test cases). Other languages fall back to regex matching.
prompts.py builds a structured prompt that injects the retrieved evidence and requests a fixed CONFIDENCE / RESOLUTION / EXPLANATION format.
resolver.py runs the prompt through the model and parses the structured response.
mergemate.py is the CLI: it displays the result, asks for human confirmation before touching any file, and — critically — validates that the resolved code is syntactically valid Python (via ast.parse()) before writing it, refusing to apply anything that would corrupt the file.

We deliberately chose plain-text retrieval over an embedding-based approach: an embedding model would add real RAM overhead we judged wasn't justified against a strict 7GB budget already spent mostly on the LLM itself.

Challenges we ran into

A duplication bug in file-writing. Early versions of the apply-to-file logic occasionally let the model's response duplicate lines already sitting in the file outside the conflict markers — sometimes with slightly different text (e.g. added type hints), which broke naive exact-match de-duplication. We rebuilt the logic to match the largest contiguous block of lines against the surrounding file content, with fuzzy matching for function signatures specifically.
Malformed model output. A 3B model doesn't always produce perfectly formatted code — we hit real cases of unclosed docstrings and dropped indentation. Rather than trust the model blindly, we added a validation-and-rollback step: if the spliced result isn't valid Python, the file is left completely untouched and the user is warned.
Thermal throttling on CPU-only hardware. Sustained inference on our development machine (no discrete GPU) intermittently triggered thermal throttling, with peak temperatures ranging from 84°C to 94°C across different runs of the identical workload — a real, honestly-documented constraint of this hardware profile, not something we could fully engineer around at the software level.
Getting a genuine test case. To validate retrieval against something real rather than hand-typed conflict markers, we built a small local project and produced an actual CONFLICT (content) from two diverging git branches — this became our strongest piece of evidence that the retrieval-augmented approach measurably improves resolution quality over the same conflict resolved without that context.

Accomplishments that we're proud of

A resolution pipeline that doesn't just guess: on a real, git-generated conflict, MergeMate found the exact test proving the correct combined behavior and cited it directly in its explanation, producing a resolution that correctly merged logic from both branches rather than picking one side.
A safety-first design where confidence signaling is mechanically enforced, not just descriptive — and where output is validated before ever touching a file.
Verified cross-language support: the same pipeline works correctly on a JavaScript conflict, using regex-based retrieval, with results matching the quality of our Python tests.
Comfortably meeting the resource target: 3.46GB peak RAM against a 7GB budget, with generation speed close to the competition's reference throughput.

What we learned

Small, quantized models are genuinely capable of structured, evidence-grounded reasoning about code — but they need real scaffolding around them (retrieval, strict output formatting, validation, confidence signaling) to be trustworthy, not just occasionally impressive. We also learned that a narrow, well-tested tool with honestly documented limitations builds more credibility than a broad, unverified one — every rough edge we found and fixed (or explicitly documented) tonight made the final submission stronger, not weaker.

What's next for MergeMate

Semantic retrieval. Move beyond exact-name-match search to embedding-based retrieval, so evidence using different naming or indirect references isn't missed — RAM budget permitting.
Broader AST support. Extend structural identifier extraction beyond Python to JavaScript/TypeScript and other supported languages, replacing the current regex fallback.
Automated syntax validation for non-Python languages, mirroring the safety net Python already has.
Rigorous accuracy benchmarking against a real dataset of historical merge conflicts (e.g. Merge-Bench), to move from "several verified real examples" to a statistically meaningful accuracy number.
Test execution as a second layer of validation — running a project's actual test suite against a candidate resolution before applying it, not just checking syntax.