Auto-migrate origin from gitlab.com to hex.wurzelraum.org via install.sh #1

Open
opened 2026-08-11 09:39:47 +00:00 by mercen.ai · 1 comment
Collaborator

Problem

This repo's source of truth moved from gitlab.com/shukutils/dits-and-dots to this
Forgejo instance. main here now has the correct remote everywhere in-repo (README,
install.sh, the SSH-bootstrap helper), but any machine that ran the installer
before the move still has its chezmoi source repo (~/.local/share/chezmoi) with
origin pointing at the old gitlab.com URL. Those machines will keep pulling from a
now-frozen mirror until someone manually runs git remote set-url on them.

Proposed fix: self-migrating install.sh

(Revised: an earlier draft of this hooked the migration check into dotpull(). Dropped
that — dotpull/dotpush were 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/chezcommit aliases, or nothing at all
on older installs. install.sh is the one thing every install/reinstall path already
goes 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.sh fresh from
origin, i.e. from gitlab.com, for now. That's our one remaining hook.

Plan:

  1. Push one final commit to the old gitlab.com/shukutils/dits-and-dots repo
    (not this one) that adds a remote-migration check to the top of install.sh,
    before the existing chezmoi init --apply logic:

    CHEZMOI_SRC="$HOME/.local/share/chezmoi"
    NEW_REMOTE="git@hex.wurzelraum.org:shukutils/dits-and-dots.git"
    
    if [ -d "$CHEZMOI_SRC/.git" ]; then
        cur="$(git -C "$CHEZMOI_SRC" remote get-url origin 2>/dev/null || true)"
        case "$cur" in
            *gitlab.com*shukutils/dits-and-dots*)
                echo "Migrating chezmoi source remote: gitlab.com -> the current forge"
                git -C "$CHEZMOI_SRC" remote set-url origin "$NEW_REMOTE"
                branch="$(git -C "$CHEZMOI_SRC" symbolic-ref --short HEAD 2>/dev/null || echo main)"
                git -C "$CHEZMOI_SRC" fetch origin "$branch"
                git -C "$CHEZMOI_SRC" merge --ff-only "origin/$branch" || \
                    echo "warning: local chezmoi source has diverged, couldn't fast-forward — leaving as-is"
                ;;
        esac
    fi
    

    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-only the
    local copy would still be stuck on whatever it last had. This also has no dependency
    on dotpull existing: it's plain git/bash, safe on any install however old.

  2. Whoever runs bash <(curl ... install.sh) next — from wherever they saved that
    command — 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 current install.sh) runs normally against the
    real origin.

  3. 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 completely
dormant 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 in
gitlab.com's README too, for anyone who finds it manually.

Scope

  • Draft and push the migration-shim commit to install.sh on the gitlab.com mirror
  • Confirm it round-trips (seed a throwaway chezmoi source dir pointed at gitlab.com,
    run the old install.sh, verify origin flips and new content lands)
  • Once the fleet's confirmed migrated, remove the shim in a follow-up commit here
    and on gitlab.com
## Problem This repo's source of truth moved from `gitlab.com/shukutils/dits-and-dots` to this Forgejo instance. `main` here now has the correct remote everywhere in-repo (README, `install.sh`, the SSH-bootstrap helper), but any machine that ran the installer *before* the move still has its chezmoi source repo (`~/.local/share/chezmoi`) with `origin` pointing at the old gitlab.com URL. Those machines will keep pulling from a now-frozen mirror until someone manually runs `git remote set-url` on them. ## Proposed fix: self-migrating `install.sh` *(Revised: an earlier draft of this hooked the migration check into `dotpull()`. Dropped that — `dotpull`/`dotpush` were 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`/`chezcommit` aliases, or nothing at all on older installs. `install.sh` is the one thing every install/reinstall path already goes 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.sh` fresh from `origin`, i.e. from gitlab.com, for now. That's our one remaining hook. Plan: 1. Push one final commit to the **old** `gitlab.com/shukutils/dits-and-dots` repo (not this one) that adds a remote-migration check to the top of `install.sh`, before the existing `chezmoi init --apply` logic: ```bash CHEZMOI_SRC="$HOME/.local/share/chezmoi" NEW_REMOTE="git@hex.wurzelraum.org:shukutils/dits-and-dots.git" if [ -d "$CHEZMOI_SRC/.git" ]; then cur="$(git -C "$CHEZMOI_SRC" remote get-url origin 2>/dev/null || true)" case "$cur" in *gitlab.com*shukutils/dits-and-dots*) echo "Migrating chezmoi source remote: gitlab.com -> the current forge" git -C "$CHEZMOI_SRC" remote set-url origin "$NEW_REMOTE" branch="$(git -C "$CHEZMOI_SRC" symbolic-ref --short HEAD 2>/dev/null || echo main)" git -C "$CHEZMOI_SRC" fetch origin "$branch" git -C "$CHEZMOI_SRC" merge --ff-only "origin/$branch" || \ echo "warning: local chezmoi source has diverged, couldn't fast-forward — leaving as-is" ;; esac fi ``` 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-only` the local copy would still be stuck on whatever it last had. This also has no dependency on `dotpull` existing: it's plain git/bash, safe on any install however old. 2. Whoever runs `bash <(curl ... install.sh)` next — from wherever they saved that command — 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 current `install.sh`) runs normally against the real origin. 3. 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 completely dormant 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 in gitlab.com's README too, for anyone who finds it manually. ## Scope - [ ] Draft and push the migration-shim commit to `install.sh` on the gitlab.com mirror - [ ] Confirm it round-trips (seed a throwaway chezmoi source dir pointed at gitlab.com, run the old `install.sh`, verify origin flips and new content lands) - [ ] Once the fleet's confirmed migrated, remove the shim in a follow-up commit here and on gitlab.com
mercen.ai changed title from Auto-migrate origin from gitlab.com to hex.wurzelraum.org on next dotpull to Auto-migrate origin from gitlab.com to hex.wurzelraum.org via install.sh 2026-08-13 10:04:48 +00:00
Author
Collaborator

I 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.

I 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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
shukutils/dits-and-dots#1
No description provided.