📚 Say the merge-rule substance in comments, not a tracker id

Two comments cited an internal work-tracker id that a code reader
cannot resolve and that the tracker may rename. Both now say what the
rule says: one side keeping its value in a merge is a recorded choice,
never a silent win.

AI-assisted-by: glm-5.3-flash
Signed-off-by: Álvaro Tejero Cantero <alvorithm@teje.ro>
This commit is contained in:
Álvaro Tejero Cantero 2026-10-07 12:44:23 +02:00
parent 9e396c1feb
commit f1f07eb52c
No known key found for this signature in database
2 changed files with 3 additions and 3 deletions

View File

@ -1057,7 +1057,7 @@
conflicts (:conflicts merge-summary)
;; an excluded conflict is resolved: the exclusion IS the
;; recorded choice, so it lands on the target side
;; (`bm/compute-changes`, `pp:vcs:ds-no-silent-winner`)
;; (`bm/compute-changes`: one side keeping its value is a recorded choice, never a silent win)
resolved? (fn [c] (or (contains? excluded (:key c))
(bm/conflict-resolved? c (get resolutions (:id c)))))
unresolved (remove resolved? conflicts)

View File

@ -1873,8 +1873,8 @@
An excluded entity is treated as resolved to the TARGET side: no change
is emitted for it and the target keeps its own value. That is the
recorded choice, not a silent win for one side (see
`pp:vcs:ds-no-silent-winner`): the user deselected the change, so the
recorded choice, not a silent win for one side: the user deselected
the change, so the
result is exactly what the target has, and a conflicting entity lands
there whatever `resolutions` says. Excluding an added shape cascades to
every shape the source places under it (its added descendants and any