Why
A user completing first-time setup ends up with the dotfiles remote still pointing to HTTPS after the GitHub install step runs, making it impossible to push changes via SSH without manual intervention.
Current state
features/install/zsh/github.zsh line 68 runs cd "$HOME/dotfiles" inside a subshell before converting the remote URL from HTTPS to SSH. The dotfiles repo is cloned to $HOME/Repos/ooloth/dotfiles (set as $DOTFILES on line 6 of the same file). The cd silently fails because $HOME/dotfiles does not exist, so git remote set-url runs in whatever directory the subshell started in — or fails entirely — and the conversion never happens. Line 84 then prints TODO: verify dotfiles remote URL has been updated to use SSH... verbatim to the user.
Ideal state
- The subshell navigates to
$DOTFILES ($HOME/Repos/ooloth/dotfiles), which is the actual clone location.
- The remote conversion succeeds when the remote is HTTPS.
- The TODO string on line 84 is replaced by a real verification step or removed.
- A user completing setup can push to the dotfiles repo via SSH immediately after the script finishes.
Out of scope
- Changes to the SSH key generation step (
ssh.zsh).
- Broader refactoring of the install flow.
Starting points
features/install/zsh/github.zsh — line 6 defines $DOTFILES; line 68 has the wrong path; lines 52–57 show a verification block that was commented out.
features/setup/setup.zsh — lines 96–100 show how $DOTFILES is set and used for the clone, confirming the actual path.
QA plan
- Inspect
features/install/zsh/github.zsh line 68 — expect cd "$DOTFILES" (or equivalent), not cd "$HOME/dotfiles".
- On a machine where dotfiles are cloned to
$HOME/Repos/ooloth/dotfiles with an HTTPS remote, source the script — expect git remote get-url origin to return an [email protected]:… SSH URL afterwards.
- Run the full setup flow on a fresh machine — expect no manual remote-URL fix required before the first SSH push.
Done when
github.zsh successfully converts the dotfiles remote from HTTPS to SSH using the correct repo path, verified by checking the remote URL after the script runs.
Why
A user completing first-time setup ends up with the dotfiles remote still pointing to HTTPS after the GitHub install step runs, making it impossible to push changes via SSH without manual intervention.
Current state
features/install/zsh/github.zshline 68 runscd "$HOME/dotfiles"inside a subshell before converting the remote URL from HTTPS to SSH. The dotfiles repo is cloned to$HOME/Repos/ooloth/dotfiles(set as$DOTFILESon line 6 of the same file). Thecdsilently fails because$HOME/dotfilesdoes not exist, sogit remote set-urlruns in whatever directory the subshell started in — or fails entirely — and the conversion never happens. Line 84 then printsTODO: verify dotfiles remote URL has been updated to use SSH...verbatim to the user.Ideal state
$DOTFILES($HOME/Repos/ooloth/dotfiles), which is the actual clone location.Out of scope
ssh.zsh).Starting points
features/install/zsh/github.zsh— line 6 defines$DOTFILES; line 68 has the wrong path; lines 52–57 show a verification block that was commented out.features/setup/setup.zsh— lines 96–100 show how$DOTFILESis set and used for the clone, confirming the actual path.QA plan
features/install/zsh/github.zshline 68 — expectcd "$DOTFILES"(or equivalent), notcd "$HOME/dotfiles".$HOME/Repos/ooloth/dotfileswith an HTTPS remote, source the script — expectgit remote get-url originto return an[email protected]:…SSH URL afterwards.Done when
github.zshsuccessfully converts the dotfiles remote from HTTPS to SSH using the correct repo path, verified by checking the remote URL after the script runs.