[SgtSwagrid]

Summary

Deletions were synced only for a file whose last change in the target came from the source (#7), but updates still overwrote whatever was downstream. Now one rule decides every file, whether the source updated, added or deleted it, and syncDeletions is gone.

The rule: every file the source has ever had is given its state in the source (its latest version, or none if deleted). That happens only if the file's state in the target is one the source had before the target last changed it, and the source has changed it since. A file's absence counts as a source state once the source has deleted it. A file the target never had is added.

Changes

• scripts/merge-files.sh: one pass over every file in the source's history replaces the old two steps (copy everything, then a separate deletion check).
  • It records each file's current state, when the source last changed it, and when the source first had each of its states.
  • It applies a file's source state only under the rule above. Git's all-zero blob for a deleted file stands for absence, so additions, updates and deletions go through the same lines.
  • It logs Added, Updated, Deleted, Kept (with the reason) or Skipped (ignored); unchanged files are no longer logged as Copied.
  • It now stops with an error on a shallow clone, as nothing can be decided without full history (the workflow always fetches it).
• scripts/publish.sh: replay(), which re-applies queued sync commits onto the latest target branch, uses the same idea. A change, whatever its kind, is applied only where the file is still as it was when the change was made. A change already present is skipped silently, and one to a file the target changed since is kept. Before, updates were always applied and only deletions were checked.
• syncDeletions is removed from parse-config.sh, load-config.sh and the README. No graph in this account sets it.
• README.md: a new "Which files are synced" section explains the rule. The syncDeletions section is gone. "Merge semantics" no longer claims updates overwrite everything, that copies shouldn't be modified, or that the most recent source wins; with this rule the first source to sync a file keeps it. The replay remark no longer refers to deletions alone.
• templates/pull-request-body.md: the default warning no longer says files with matching names are overwritten.
• sync.yml: the comment on full history no longer mentions deletions alone.

Behaviour

Target's file	Before	Now
synced, untouched; source updates or deletes it	updated / deleted	updated / deleted
modified in the target; source updates it	overwritten	kept
deleted in the target; source updates it	re-added	kept
the target's own, from before the source added it	overwritten	kept
re-added after its deletion was synced	kept	kept
deleted by a synced deletion; source re-adds it	added	added
never in the target; source adds it	added	added
first from an earlier source, then synced by this one	updated	updated
ignored	untouched	untouched

So a file changed downstream stops following the source altogether. To make it follow again, give it the source's latest version.

Testing

No CI exercises the scripts, so I ran them against repositories built with known commit times:

• merge-files.sh: one file per case above, plus the earlier scenarios (merge commits, a file re-added in the source after a synced deletion). Every case came out as in the table. The previous script, on the same histories, overwrote or restored the three files it now keeps.
• replay(): a sync commit, made on an old base, replayed onto a newer base where the target had changed some files meanwhile. Its update, addition and deletion applied; the target's changed file, a file it changed that the sync deleted, and a file it added itself were kept; a change already present was skipped. The previous replay() overwrote two of those three files.
• bash -n passes for every script.

Notes

• Every config runs sync.yml@main, so this applies to every sync as soon as it merges.
• A file whose target version came from an earlier source, and is a version the current source never had, now stays as it is, as if the target had changed it. That is only possible where a repository was moved beneath a new parent and its syncs from the new parent were never merged. Such files show as Kept: <file> (changed in the target) in the sync logs.

🤖 Generated with Claude Code