andreandClaude Opus 5
4d40adbf64
shared/platform-tools was a git submodule. On this branch it is a plain
directory of tracked files, frozen at ea3616abae30106df283e73a3e2f9e5bb0e6ae90
— the same commit fotografia.andmore.pt pins. Contents are byte-identical to
that tree, verified blob by blob.
The submodule caused every deployment failure this site has had:
- .gitmodules named no `branch`, so the update fell back to
refs/remotes/origin/HEAD — a ref a plain server-side clone never writes.
"Atualizar submódulo" failed with "Unable to find refs/remotes/origin/HEAD
revision in submodule path".
- Its URL was http://, which the origin answers with 523.
- This install is deployed by uploading files, and a submodule is invisible
to that. The tree moved forward while shared/platform-tools stayed on the
old pin, config/functions_secrets.php died on a missing compat_secrets.php,
and the whole site — public pages included — went down.
Each of those was separately fixable. Together they mean a second repository
nobody can see from the deployment path, gating whether the first one boots. A
plain directory deploys like every other file and cannot fall out of step.
The cost is that platform-tools updates no longer arrive by bumping a pin; they
are a copy-over-and-commit. shared/platform-tools/VENDORED.md records the
upstream SHA, the procedure, and which four files differ from upstream in line
endings only (social/*.js, .css, functions_publications.php — CRLF upstream,
normalised to LF here; content otherwise identical).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.9 KiB
platform-tools is vendored here, not a submodule
This directory used to be a git submodule pointing at
git.andmore.pt/andre/platform-tools. On the main branch it is a plain
directory of tracked files.
Frozen at: ea3616abae30106df283e73a3e2f9e5bb0e6ae90
(feat: o feedback passa a servir os três stacks da frota — the same commit
fotografia.andmore.pt pins.)
Why
The submodule was the single biggest source of deployment failures on this install:
.gitmodulesnamed nobranch, so "Atualizar submódulo" fell back torefs/remotes/origin/HEAD, a ref a plain server-side clone never creates. It failed withUnable to find refs/remotes/origin/HEAD revision.- Its URL used
http://, which the origin answers with 523. - The site is deployed by uploading files. A submodule is invisible to that:
the rest of the tree moved forward while
shared/platform-toolsstayed on an old commit, andconfig/functions_secrets.phpthen died on a missingcompat_secrets.php— taking every page, public ones included, down with it.
A plain directory deploys like every other file. There is no second repository to be out of step with the first.
The trade-off
Fixes to platform-tools no longer arrive by bumping a pin. To take an update:
- Clone or pull
platform-toolssomewhere separate. - Check out the commit you want.
- Copy its files over this directory (delete removed ones).
- Update the SHA above, and commit here with that SHA in the message.
Keep recording the upstream SHA. It is the only thing that makes "which version is this?" answerable.
Note on line endings
social/engine.js, social/functions_publications.php, social/page.js and
social/publications.css are stored upstream with CRLF. They were normalised to
LF when vendored. The content is otherwise byte-identical; diff with
tr -d '\r' to compare against upstream.