Your resolutions are remembered and replayed
Resolve once; the same conflict tries not to ask twice.
Written By Dustin
Last updated About 3 hours ago
Resolving the same conflict repeatedly — every rebase, every re-sync, every time a long-lived lane catches up — is one of the more demoralizing parts of using Git. TOVIO records each resolution and replays it when the same conflict comes back.
There are two caches doing this, and they have usefully different reach.
The whole-file cache
When you resolve a path by taking a side, the decision is recorded against the change pair, the path, and the exact content of all three sides.
That last part is the important limit: it matches only when the same conflict recurs with byte-identical sides. If either side's content has moved on, the key does not match and you are asked again. That is deliberate — a stale whole-file resolution replayed over changed content would silently discard the new work.
The region cache
Alongside it, each conflicting region gets its own entry keyed on a fingerprint of the region's surrounding content rather than a line number or a whole-file hash. This is the one with real reach:
- It survives edits elsewhere in the file. Adding fifty lines at the top does not invalidate a resolution recorded at the bottom.
- It survives history rewriting. The key uses change ids, which are stable across amend, rebase and squash — so a resolution recorded before a rebase still matches afterwards, even though every commit hash changed.
The change pair is sorted before it is keyed, so a resolution recorded merging A into B matches the same conflict met as B into A.
This cache is also where partial resolution comes from: if replay matches some of a conflict's regions and not others, it resolves what it recognises and leaves the rest open.
It refuses to guess
If a stored key matches more than one region in the current merge, the resolution is not applied and the conflict stays open. Safety over cleverness: a rare repeated-region case costs you one manual resolve, rather than silently applying your decision to the wrong hunk.
Resolutions are also stamped with the merge engine's version. If the merge rules change, older resolutions are not replayed — an old decision cannot be quietly re-applied under new semantics.
Seeing why a replay did or did not happen
tovio explain rereretovio explain rerere <path>Traces the replay for your current conflicts and says exactly why each one did or did not match — a version bump, a shifted fingerprint, or simply nothing recorded yet. When a conflict you have definitely resolved before comes back, this is the command that tells you which of the two caches missed and why.
Where it lives
The index — the map from key to resolution — is local to your repository under .tovio/, is never synced, and is not shared by pushing. Each machine builds its own; your colleague does not inherit your resolutions.
The resolved content those entries point at is stored as ordinary objects, like any other content in the repository. On a protected path the index is sealed at rest and the content is sealed under the path's policy, so a resolution is readable only by someone who could have read the file. An index that cannot be opened is treated as a miss — you get asked again, which is the safe direction to fail.