Record the git-over-HTTP TCC blocker and the SSH push route

Git cannot reach Mini-EQ over HTTP on this machine - it fails with 'No
route to host' while curl to the same address returns 200, because the
Local Network entitlement is per-binary. The remote URL is unchanged and
now transparently rides SSH via url.insteadOf. Also recorded that the
remote main can move without the local branch.
This commit is contained in:
B.D. Murphy
2026-11-06 17:13:41 -08:00
parent bf83bb35cc
commit ff5fe0402d

View File

@@ -416,6 +416,20 @@ Each pass has quality gates. Quality is the primary concern; generation speed is
- **Mini-EQ addressing quirk**: `mini-eq` resolves to **192.168.123.138**, and the server is
also reachable at **192.168.123.18** — verified the *same* machine (identical Gitea, SSH
banner, ED25519 host key). Both forms are in `known_hosts`.
- **⚠ `git` over HTTP to Mini-EQ is blocked by macOS Local Network privacy (TCC), but SSH
works.** `git push minieq main` fails instantly with *"Immediate connect fail for
192.168.123.18: No route to host"* — while `curl http://192.168.123.18:3001/api/v1/version`
returns **200** from the same shell. It is **per-binary**: `/usr/bin/git` lacks the Local
Network entitlement, `curl` has it. The symptom is misleading because `nc -z` also reports
the port **open**. Fix in place (repo-local `.git/config`, already applied):
`git config url."ssh://git@mini-eq:2222/umbragit/".insteadOf "http://192.168.123.18:3001/umbragit/"`
— the HTTP remote URL is unchanged and now transparently rides SSH. Use
`GIT_SSH_COMMAND="ssh -o BatchMode=yes -o ConnectTimeout=10"` for the push itself; without
it git's bundled ssh got *"Undefined error: 0"* on connect (also TCC-shaped).
- **The remote `main` can move without the local branch.** A push was rejected *"fetch first"*
because the remote had a commit (the Apache-2.0 LICENSE/SPDX headers) that the local branch
did not — **fetch before assuming the local history is the whole story**, and merge rather
than force. The merge was clean and is now in both histories.
- **Gitea SSH lives on :2222, not :22.** :22 is the *system* sshd and its
`AuthorizedKeysCommand` is not wired to Gitea, so **no SSH key added in the Gitea UI ever
works on :22** — enabling Gitea's built-in SSH server (`:2222`, `OpenSSH_10.0`) is what