Auto-migrate origin from gitlab.com to hex.wurzelraum.org via install.sh #1
Labels
No labels
bug
docs
feature
human-input-needed
prio
high
prio
low
prio
medium
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
shukutils/dits-and-dots#1
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
This repo's source of truth moved from
gitlab.com/shukutils/dits-and-dotsto thisForgejo instance.
mainhere now has the correct remote everywhere in-repo (README,install.sh, the SSH-bootstrap helper), but any machine that ran the installerbefore the move still has its chezmoi source repo (
~/.local/share/chezmoi) withoriginpointing at the old gitlab.com URL. Those machines will keep pulling from anow-frozen mirror until someone manually runs
git remote set-urlon them.Proposed fix: self-migrating
install.sh(Revised: an earlier draft of this hooked the migration check into
dotpull(). Droppedthat —
dotpull/dotpushwere only introduced in the most recent consolidation commit,and the gitlab.com mirror is currently frozen a few commits before that, so machines
stuck there may only have the old
bashupdate/chezcommitaliases, or nothing at allon older installs.
install.shis the one thing every install/reinstall path alreadygoes through regardless of how stale the local shell functions are, so the migration
check belongs there instead.)
We can't reach out to old machines, but they do still reach out to us whenever
someone re-runs the installer (a bookmarked link, the SSH-bootstrap helper before it
too got fixed, a cron job, whatever) — and that always fetches
install.shfresh fromorigin, i.e. from gitlab.com, for now. That's our one remaining hook.Plan:
Push one final commit to the old
gitlab.com/shukutils/dits-and-dotsrepo(not this one) that adds a remote-migration check to the top of
install.sh,before the existing
chezmoi init --applylogic:Rewriting the remote alone isn't enough — chezmoi won't reinitialize/reclone into an
already-existing source dir, so without the explicit
fetch+merge --ff-onlythelocal copy would still be stuck on whatever it last had. This also has no dependency
on
dotpullexisting: it's plain git/bash, safe on any install however old.Whoever runs
bash <(curl ... install.sh)next — from wherever they saved thatcommand — gets migrated on the spot: remote flipped, latest commits fetched, then
the existing
chezmoi init --apply "$REPO"(and, once that content lands, the.bashrc-include logic from the currentinstall.sh) runs normally against thereal origin.
Once migrated, everything downstream (dotpull/dotpush if present, or just future
manual reinstalls) naturally operates against the correct origin from then on.
Caveat: this only fires when something re-runs
install.sh. Anything completelydormant still needs a manual
git -C ~/.local/share/chezmoi remote set-url origin git@hex.wurzelraum.org:shukutils/dits-and-dots.git— worth a one-line callout ingitlab.com's README too, for anyone who finds it manually.
Scope
install.shon the gitlab.com mirrorrun the old
install.sh, verify origin flips and new content lands)and on gitlab.com
Auto-migrate origin from gitlab.com to hex.wurzelraum.org on next dotpullto Auto-migrate origin from gitlab.com to hex.wurzelraum.org via install.shI don't have credentials for the old gitlab.com/shukutils/dits-and-dots mirror from this sandbox (no token/netrc/SSH key configured for gitlab.com) — only for this Forgejo instance. So I can't push the migration-shim commit described in the plan (step 1).
Can you either (a) push that shim commit to the gitlab.com mirror yourself, or (b) give this environment a gitlab.com PAT so I can do it? I've left the rest of the checklist (round-trip confirmation, later shim removal) undone pending that.