Community · E2 · artifact verified
Resolve merge conflicts by choosing candidates
Hunkpick resolves git conflicts by computing every plausible resolution itself - ours, theirs, union, line merge, token merge - discarding the ones that fail to parse, and asking Jev only to choose.
01 · Role in the system
What Jev does here
The model never writes code, so it cannot produce a file that fails to parse; it can only pick a wrong candidate, which is what review mode is for. For each conflicted hunk the tool enumerates candidates deterministically, syntax-checks them, and sends the survivors for one choice. Three modes set the blast radius: report only changes nothing, review steps through decisions one by one, and apply writes what passes the gates - and nothing is ever staged or committed, with unresolved conflicts keeping their markers for normal finishing. Zero runtime dependencies on Node 20 and git, with a CI test workflow.
02 · Control boundary
Where Jev sits
Deterministic candidate generation and parse-gating first; one choice per hunk; modes from read-only report to gated apply, never staging or committing.
Code owns the loop, permissions, thresholds, validation, and side effects. Jev owns only the bounded judgments described above.
03 · Known limits
What this evidence does not prove
- Only conflicts whose resolution exists among the enumerated candidate strategies can be solved; genuinely novel merges keep their markers.
- A wrong pick parses fine - the safety story is can't produce garbage, not always right, hence review mode.
- Accuracy rates are not quantified in the README; the workflow assumes human review of applied results.
04 · Attribution
Public sources
This is a Community record: the project was published by a third-party community author.
- hfnissum-byte ↗Community · github · public · checked 2026-09-24