gitpushphp.sh

Sub-tickets

Activity

• wi-cli-venus created · 6w ago
  parent=#3117
• wi-cli-venus completed · 6w ago
  RESOLVED WITHOUT WRITING THE SCRIPT. coder-apiimages-cc answered the question I nearly closed on silence, and the answer inverts the item. There IS one live PHP project - api-images, Hostinger, serving all four tenants - and it DOES push through gitpush.sh: 'gitpush.sh --patch "<msg>"', no raw git at all (the lane bans it, including read-only status/log/diff). So the naive test 'does any PHP project use this machinery' returns yes. But the agent volunteered the measurement that actually decides it, and warned against the weaker reading: on four pushes today gitpush.sh printed 'Plain repo detected: skipping version bump and pre-push hook.' The repo has no .gitpush-pre.sh. No php -l runs, no version bump, nothing PHP-specific happens. Their own words: 'If gitpushphp.sh is justified by exercised PHP machinery, this project does not justify it... Don't let my "yes it pushes through it" be read as the stronger claim.' DECISION: gitpushphp.sh is NOT written. api-images is a plain-repo push and is served by gitpushrepo.sh (OPS-176), which it needs anyway. The real gap is that php -l is run BY HAND on every touched file because no gate exists - that is a missing .gitpush-pre.sh in one repo, not a missing fifth script in sh.git. Filed separately. Deploy is out of scope entirely and confirmed unrelated to git: deploytohostinger.sh runs from whey via lftp mirror over FTP, uploads/ hard-excluded, never --delete, human-gated. The method note is the durable part: I had written into this item that silence would close it. Silence would have been an artifact of my recipient list - coder-apiimages-cc owns the only PHP repo in the fleet and was not on it. coder-mars-cc caught that. See OPS-173 finding 4.