fix(git): pin auto-init default branch to main#472
Merged
Conversation
…teInstead `git init` (no `-b`) honours the server's `init.defaultBranch`, which on a server configured for e.g. `gh-pages` makes pushes to `main` silently fail to extract the working tree (the ref updates but `receive.denyCurrentBranch updateInstead` only fires when the push matches the branch HEAD points at). Pass `-b main` explicitly so the auto-init'd HEAD is deterministic regardless of server config. `git push pod HEAD:main` then works on every deployment. Adds a test reading `.git/HEAD` and asserting `ref: refs/heads/main`. Fixes #471
This was referenced May 16, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #471.
What
tryAutoInitReponow callsgit init -b main <path>instead of baregit init <path>. The auto-init'dHEADpoints atrefs/heads/mainregardless of the server'sinit.defaultBranchsetting.Why
receive.denyCurrentBranch updateInsteadonly extracts the working tree when the incoming push targets the branchHEADpoints at. If a server hasinit.defaultBranch=gh-pages(e.g. an operator who lives in GitHub Pages land), thengit push pod HEAD:mainsucceeds at the protocol layer — the ref is created — but no files appear on disk and the path returns 404 for every resource. Silent failure that's invisible at the protocol layer.Bit us during end-to-end install testing of solid-apps (chrome, vellum, etc.) on jspod. Workaround was "know the server's
init.defaultBranchand push to that name" — not acceptable for a public-facing onboarding flow.Behavior change
init.defaultBranchmainmasterpush HEAD:masterworks;HEAD:mainsilently failspush HEAD:mainworksgh-pagesHEAD:gh-pagesworkspush HEAD:mainworkspush HEAD:mainworksUsers pushing to a non-
mainbranch name will continue to see refs accepted but the working tree not extracted (same as today, just now consistent across deployments). The wrapper docs (jspod) will note "push tomain".Optional follow-up
A
--git-default-branch <name>server flag (defaulting tomain) would let operators override without an explicit per-request mechanism. Not needed for this fix; can file separately if anyone asks.Test plan
pins the initial branch to \main` regardless of server configintest/git-auto-init.test.js— reads.git/HEADafter auto-init and assertsref: refs/heads/main`test/git-auto-init.test.jspass locally on this branch