* fix(#4558): report a byte-identical restore destination as already_present restore-custom-files treated a destination that is byte-identical to its backup exactly like a missing one: plan reported it as `eligible`, --apply re-copied the same bytes and reported `restored`, and both counters included it. Because update.md drives its restore question off eligible_count, the workflow re-offered the same no-op restore on every update and accepting it never settled anything. Emit a distinct `already_present` outcome for that case. It is excluded from eligible_count and restored_count, --apply writes nothing for it, and the backup is left intact. A differing destination is still skipped_destination_exists and a missing one still restores normally. Regression tests cover the identical-destination plan/apply paths, the idempotence-after-success cycle (missing -> restored -> silent plan), and a mixed backup. Docs for the outcome enum are updated to match. * fix(#4558): tighten already_present wording after review update.md's RESTORE_ELIGIBLE == 0 branch now also names the already-present case, CLI-TOOLS.md no longer calls the follow-up plan run "silent" (the entry is still reported, just never offered), and a test message reads correctly. * chore(#4558): add changeset fragment for #4599 * chore(#4558): acknowledge update.md growth from the restore-outcome guidance Emitted-Drift-Ack-Growth: update.md — added already_present restore-outcome guidance for #4558 --------- Co-authored-by: TwistedRiCen <16397953+TwistedRiCen@users.noreply.github.com> Co-authored-by: Tom Boucher <trekkie@nomorestars.com>
This commit is contained in:
@@ -1247,7 +1247,7 @@ node gsd-tools.cjs restore-custom-files --config-dir <config-dir> --apply
|
||||
| Field | Meaning |
|
||||
|---|---|
|
||||
| `path` | Path relative to the config dir — where the file came from and goes back to |
|
||||
| `outcome` | `eligible` (plan mode) · `restored` · `skipped_destination_managed` · `skipped_destination_exists` · `skipped_copy_failed` · `skipped_unsafe_path` |
|
||||
| `outcome` | `eligible` (plan mode) · `restored` · `already_present` · `skipped_destination_managed` · `skipped_destination_exists` · `skipped_copy_failed` · `skipped_unsafe_path` |
|
||||
| `warnings` | Advisory `{code, detail}` findings from the compatibility pass; never blocks a restore |
|
||||
|
||||
Warning codes: `destination_managed`, `destination_exists`,
|
||||
@@ -1262,9 +1262,12 @@ retired, invokes a `/gsd:` command that no longer exists, or is missing the
|
||||
Three things the restore never does: it never deletes the backup, it never
|
||||
overwrites a path the new release ships (`skipped_destination_managed`), and it
|
||||
never overwrites a different file already on disk
|
||||
(`skipped_destination_exists`). Symlinked backup entries are skipped outright
|
||||
rather than followed (`skipped_unsafe_path`). A single unwritable entry is
|
||||
reported and the remaining entries still restore.
|
||||
(`skipped_destination_exists`). A destination that is already byte-identical to
|
||||
its backup is reported as `already_present` and left untouched — it counts
|
||||
toward neither `eligible_count` nor `restored_count`, so a plan run after a
|
||||
successful restore no longer offers the same file again. Symlinked backup
|
||||
entries are skipped outright rather than followed (`skipped_unsafe_path`). A
|
||||
single unwritable entry is reported and the remaining entries still restore.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user