Note that followRemoteHEAD invents a URL-less origin

Git materialises a remote from the existence of any remote.<name>.* key,
so remote.origin.followRemoteHEAD makes `git remote` list an origin in
every repo without one - this dotfiles repo included. It reads as a
broken remote to anyone looking, and has now been misdiagnosed as
leftover cruft twice. Nothing is actually wrong: get-url still fails, so
the guards in git-sync and nvim's default_branch() hold. Say so in both
places someone would look.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jonny Barnes 2026-08-31 21:45:12 +01:00
commit 3b4b84fb20
No known key found for this signature in database
2 changed files with 12 additions and 0 deletions

View file

@ -85,6 +85,12 @@ doing so. `git remote` sorts alphabetically, so picking the first remote in
be-edition returns `kdog` — a colleague's fork. nvim's `<leader>gm`
(diff-against-branch) tries `origin`, then `upstream`, then the rest.
One wrinkle: setting `remote.origin.followRemoteHEAD` at all is enough for git to
invent the remote, so `git remote` lists a URL-less `origin` in repos that have
none — this one, whose remotes are `forge` and `github`. It is a listing
artefact, not a real remote: `git remote get-url origin` still fails, so the
`origin` guard in `git sync` and the fallbacks in `<leader>gm` behave.
## Light and dark mode
Most of this is now handled natively and needs no configuration: