Merge: the same name added on both sides with identical content unifies issue #101 closed: completed andymccall opened this · 3 comments
andymccall set labels bug, gap ·
Analysis 2026-10-12: the tree view (crates/oxy-core/src/tree.rs, the Name conflict near line 696) builds paths from placements without file contents, so two separately added nodes with the same (parent, name) are a conflict there by construction; unifying them belongs one level up. Proposed: in oxy merge (and the import's merge), after the merged state is built, for each TreeConflict::Name whose nodes are all the same kind with identical content (same bytes and mode for a file, the same pin for a subrepo, the same target for a link), record a resolution in the merge's working copy that retires all but the oldest node's placement, and say so ('rstar-api: added on both sides identically, kept once'). Different content stays a conflict, with status/resolve saying which side to keep. Deferred from the overnight loop as a core-semantics change that wants Andy's eye; not started.
Status 2026-10-14: still open for Andy's call. The reported case is a subrepo, and a conflicted subrepo is not on disk at all, so the existing resolution (delete one candidate file, rename the other) cannot unify it. The fix needs resolution tree ops written by the merge itself: for each name conflict whose candidates are the same kind with identical content (same bytes and mode, the same pin, the same link target), RemoveNode for every candidate's placement but the oldest's. Two ways to land them:
- In the working copy after
oxy merge(uncommitted, shown in status as 'rstar-api: added on both sides identically, kept once'), committed with the user's next commit. Least surprising; nothing is recorded without the user. - As a recorded Resolution change that the merge commits and signs. The bookmark is clean at once, but the merge then records a change of its own.
My recommendation: 1.
Decided by Andy (2026-10-18): the same path added on both sides with identical content unifies silently in the working copy: no conflict, nothing to resolve, no resolution change recorded.
closed by change c2e1d09047db ·
andymccall referenced by change 6f06d9f912b4 on main ·
From oxygen_feedback.md (supermarioland2, 2026-10-10): the same subrepo (rstar-api, same pin) added on two bookmarks conflicts on merge (tree: Name conflict, rstar-api.oxy-conflict-1/-2 that do not exist on disk). Identical adds should unify, as Git does. Failing that, status/resolve should say which side to keep and how.