Cloning the forge repo on Windows and running the suite there turned up two
things a checkout inside the monorepo could never show, because this working
copy has core.autocrlf=false.
Git on Windows defaults to autocrlf=true, so a fresh clone gets CRLF. For
most files that is cosmetic. For shell scripts it is not: install.sh copied
from such a clone onto a server fails with `bash: \r: command not found`,
which tells the person almost nothing about what is wrong. And a
CRLF-rewritten .patch file is no longer the bytes `patch` was given.
.gitattributes now pins eol=lf for the scripts, the container inputs and the
source, and marks *.patch as binary so nothing rewrites it at all.
tools/refresh-patches.sh --check also compares with --strip-trailing-cr, so
a clone made before this landed reports honestly instead of claiming the
patch record has drifted when it has not. A check that cries wolf is a check
somebody switches off.
The subtree is in place, so everything that used to fetch and patch core at
build time now just copies it.
tools/build.sh copies wordpress/ — no download, no checksum step,
because there is nothing to fetch and nothing to
trust that is not already in the repository
docker/Dockerfile COPY wordpress/ instead of curl + sha256 + patch;
the build args and the `patch` package are gone
docker-compose.yml no WP_VERSION / WP_URL / WP_SHA256 to keep in step
tools/update-wordpress.sh is rewritten around what the subtree makes
possible. It imports the pristine release onto sirius-press/wordpress-upstream
and then `git subtree merge`s that branch, which three-way merges upstream
against the fork's own commit. A patch either applies with fuzz and hopes or
fails and leaves you re-deriving the change by hand; a merge conflict is
resolved once, in the file, and the next release merges against the
resolution.
patches/ survives as documentation rather than mechanism, and is now
generated: tools/refresh-patches.sh diffs the subtree against the pristine
import and rewrites the directory, with --check for CI. It answers the
question anyone auditing a fork asks first — what exactly did you change
inside WordPress? — in a minute, which `git log wordpress/` cannot, because
that log is mostly upstream imports. Generated documentation stays true; a
hand-maintained record of a core diff drifts, and a stale one is worse than
none because people trust it.
One test change worth noting: the syntax sweep no longer walks all of
wordpress/. It lints the fork's own PHP plus every core file patches/ says
the fork touches, which keeps the suite at seven seconds instead of a minute
while still covering the only core file that can break.
