Resolving a conflict must keep both versions available
Aliases: preserve both sides · conflict copy · don't discard
What it is
A conflict can be seen and the resolve step can still wipe one side off the world. Keep both versions requires: before a person chooses, and at the moment of choosing, both originals are still there, still reviewable, still eligible to enter the result. Resolution may be “A only”, “B only”, or “stitch C”; it may not be “B is already gone so you can only have A”. The lost side was not rejected. It was destroyed.
This leaf assumes the conflict has already been surfaced. It answers the fate of the originals during resolve, not whether a dialog appears, and not whether fields can auto-merge.
Why it happens
People resolve by contrast: holding A’s sentence and B’s sentence in working memory. Working memory will not hold a whole document, so contrast needs an external anchor — both copies reachable on screen. Delete one side and contrast becomes recollection; recollection turns “I think I wrote a sharper line” into uncertainty, and people settle for whatever remains. Destruction is therefore not a neutral storage optimisation. It changes the decision from comparison to making-do.
A second layer is later regret. A wrong choice must be able to retrieve the unchosen original. If the resolve button physically deletes the unchosen side, regret depends on backup luck. Keeping both demotes the unchosen side to “an archived candidate”, rather than pulling it out of the object graph. In collaboration this is also the other author’s labour: destroying B is a unilateral ruling that B’s work does not enter history.
Where it stops holding
Two byte-identical copies need only one kept; that is not conflicting content. Malicious or unlawful content (a leak, an abusive write) can be access-controlled while still retained; it need not be shown to everyone who opens the document. The audit side should still have a trace. Extremely large objects (two multi-gigabyte videos) may keep references and previews rather than inline both bitstreams, but the reference must actually open the original. After a person has explicitly “discard this side” and confirmed, a trash or version history is a weaker form of keeping — acceptable if the original is still there before confirm, and confirm cannot be a single miss-tap. When auto-merge succeeds and both edits entered the result, what is kept is the synthesis plus history; the two full texts need not sit side by side forever.
Applying it
- The conflict UI presents both originals at once; by default it deletes neither. Choosing “use this version” moves the other into an openable “not adopted” version, rather than vanishing it at once.
- Offer “keep both”: at least allow unchosen passages to be copied into the result, rather than single-select only.
- After resolve, version history can still locate both originals at that conflict.
- How to check: manufacture a title conflict. After choosing the left, without refreshing, find the right-hand sentence. If it cannot be searched and the version history has no other side for that conflict, that was destruction, not resolve. Undo the resolve: both sides should return, not only the chosen one.