Pass --update to fetch-repos.py from init-version.sh

[claude]

Requested by Thomas · Slack thread

Before: scripts/init-version.sh calls scripts/extensions/fetch-repos.py with --repos and --target and nothing else. fetch-repos.py treats an existing checkout as done: if the destination already has a .git directory and --update was not passed, it prints [skip] <path> already cloned and returns success without touching the tree. The result is that every extension checkout is frozen at whatever revision it was first cloned at. Editing a manifest changes nothing on disk, because the clone already exists — the edit is silently skipped on every subsequent run. That is the mechanism behind Sentry MEDIAWIKI-CEX (99 events): <timeline> tags fail to render because the Timeline checkout is stuck on a revision from a one-month window in which it referenced a class that only exists in MediaWiki 1.46. Upstream fixed it a month later, but the fix has never been fetched.

After: The invocation passes --update, so existing checkouts are brought to the branch the manifest pins. fetch-repos.py's git_update() runs git fetch --depth=1 origin <branch>, git checkout <branch>, then git reset --hard origin/<branch>. Manifest edits now actually take effect on a re-run, and stale checkouts like Timeline move forward to current upstream.

How: One line added to the existing invocation in scripts/init-version.sh, matching the surrounding \ line-continuation style. --update is already a supported flag on fetch-repos.py (parser.add_argument('--update', action='store_true', help='Pull latest in existing repos')) — nothing in the Python is changed.

The trade-off, stated plainly. This genuinely changes deploy behaviour, and it is not a no-op cleanup. Today a re-run of init-version.sh leaves existing checkouts untouched, which has been acting as an accidental freeze. After this change, a re-run moves every existing checkout to the manifest's pinned branch and does so with reset --hard, discarding any local modifications in those directories. That is the intent — it is what makes the manifests authoritative again — but it means the next build will pull in upstream changes that have been frozen for however long each checkout has been sitting there, all at once, across every extension and skin, not just Timeline. Some of those extensions have not moved with this tree in a long time. This deserves a staging run and a look at what actually changes before it is merged and run against production; it should not be a blind merge.

What was verified, and what was not. Verified from here: bash -n scripts/init-version.sh parses clean; the skip-early behaviour, the --update flag definition, and the exact git_update() command sequence were each read directly in scripts/extensions/fetch-repos.py. shellcheck is not installed in this environment, so it was not run — please don't read this as shellcheck-clean.

Not verified: this was not run against a real MediaWiki tree. No init-version.sh execution, no checkout updated, and no page rendered — so the claim that this clears MEDIAWIKI-CEX follows from the code path, not from an end-to-end test. A staging run is the way to confirm it, and is worth doing for the trade-off above regardless.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AiEBkhzV1z9bEykvEU9U8j

---

Generated by Claude Code

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 36384233-4c4a-4595-9533-9bf051e2745f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}