A squashed initial commit left 68 template-built sites running 28 versions

Merge and rebase are both defined against a merge base, and a repository created from a template does not have one ^[8]. `--allow-unrelated-histories` does not manufacture one. It tells git to proceed regardless, at which point every path present in both trees arrives as a conflicting add, because git is looking at two unrelated projects that happen to share filenames ^[7]. The refusal message accurately describes the repository you asked for ^[6].

Cherry-pick sidesteps the whole question because it never reconciles histories, it applies a patch ^[9]. The author runs `git cherry-pick --no-commit`, then rebuilds the commit from the upstream metadata: original author, original date, original message, all read out of the template with `git log -1` ^[10][11]. That detail is the part worth copying. An rsync of the template tree gives you a single opaque commit called something like "sync with template", dated today, authored by whoever ran the script, and six months later in a bisect those two histories are not the same artifact ^[12].

The reason a conflict-only protection rule loses a logo is that there is no conflict. A template commit can overwrite the file cleanly, nothing gets arbitrated, no warning prints, and the rule never fires ^[14]. So ownership has to be declared in two tiers. Files the repo owns outright, logo, favicon, hostnames, `.env`, `docker-compose.yml`, are restored from the repo after every replayed commit whether or not anything conflicted, because there is no sensible three-way merge of a PNG or a hostname ^[15]. Files it owns partly, a stylesheet that is mostly template plus a local palette, a translations directory, win only on conflict; protect those absolutely and they never receive another upstream fix ^[16]. Everything else belongs to the template, and each file the template overwrites is printed at the end of the run ^[17].

At fleet scale, two problems in the replay surface. Cherry-pick refuses a merge commit unless you name a mainline with `-m`, and naming one duplicates content both parents already contributed, so the replay range wants `--no-merges` ^[18][19]. And a run that dies on commit 14 of 20 must not stop and report, because the repo then holds part of the template's changes while its version file, and every dashboard, script and flag keyed to that file, asserts a state it is not in ^[20].

One distinct version per 2.4 sites is the census compressed to a single figure ^[22], and the spread runs across the whole fleet rather than a handful of stragglers. Two thirds of the fleet came in through the button, 68 of roughly a hundred repositories ^[1][23], and the four sites still on major 1 are about 6% of them ^[24]. What the post does not measure is how many upstream commits failed to land; the security fix on day 30 and the dependency bump on day 200 are offered as an illustration of the gap, not a log of it ^[21]. The author's diagnosis puts the cause in the missing mechanism to keep the sites in sync, rather than in any individual or process failure ^[4]. That reading holds, and it prices the adoption cost honestly: the template repo only ever provided a starting point ^[5], and whatever you build to be the channel needs a per-repo ownership manifest before its first run ^[15][16].