fix(update): stop mcupdate asking for a GitHub username

GitHub's HTTP/2 front end began answering the anonymous git-upload-pack
POST with 401 for the git 2.39 / libcurl 7.88 build that ships with
Debian 12. Git reads any 401 as a credential request, so update.sh sat
on "Username for 'https://github.com':" against a public repo, on every
server at once, with nothing changed locally.

Pull with http.version=HTTP/1.1, which GitHub still serves anonymously,
and set GIT_TERMINAL_PROMPT=0 so a genuine auth failure errors out
instead of blocking on stdin forever. Documented in troubleshooting,
README and whatsnew, including the one-off git config for installs too
old to carry the fix.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -353,6 +353,8 @@ python3 -m app.version freeze
 docker compose up -d --build
 ```
 
+If `git pull` asks for a `Username for 'https://github.com'`, it is not asking for credentials you are missing — see [Update asks for a GitHub username](docs/troubleshooting.md#update-asks-for-a-github-username).
+
 The `python3 -m app.version freeze` command captures the current Git build (date + commit hash) for display in the app menu, underneath the release number from the `VERSION` file. Released versions are tagged `v<version>` and published at [Releases](https://github.com/MarekWo/mc-webui/releases); see [Versioning & Releases](docs/architecture.md#versioning--releases) for how a release is cut.
 
 ### Testing experimental features

docs/troubleshooting.md

@@ -172,6 +172,34 @@ You can also check the System Log in the web UI (Menu → System Log) for real-t
 
 ---
 
+### Update asks for a GitHub username
+
+`mcupdate` (or a plain `git pull`) stops and waits at:
+
+```
+Username for 'https://github.com':
+```
+
+even though mc-webui is a public repository that needs no credentials.
+
+This is not an authentication problem, and nothing is wrong with your install.
+GitHub's HTTP/2 front end rejects the anonymous `git-upload-pack` request sent
+by older git builds — notably the `git 2.39` / `libcurl 7.88` combination that
+ships with Debian 12 — and git reports that `401` as a credential prompt.
+Press Ctrl+C; typing a username or a token will not help.
+
+**Fix** — tell git to speak HTTP/1.1 to GitHub:
+
+```bash
+git config --global http.version HTTP/1.1
+```
+
+Then run `mcupdate` again. From 2.14.0 on, `update.sh` sets this for its own
+pull, so the manual command is only needed to update *to* that version — or for
+`git pull` commands you run yourself.
+
+---
+
 ## Recording a Diagnostic Capture
 
 Some problems cannot be diagnosed from a screenshot or a log excerpt — most often

docs/whatsnew.md

@@ -18,6 +18,8 @@ For deep technical notes, see [architecture.md](architecture.md). For the full g
 
 ### Fixes
 
+- **Updating no longer stops at a GitHub username prompt.** `mcupdate` started halting on its very first step, showing `Username for 'https://github.com':` and then sitting there waiting for something to be typed — on every server at once, on the same day, with nothing having changed on any of them. It is an odd thing to be asked by a repository that is public and has never needed a login, and nothing was wrong with the installs: GitHub changed how its front end answers the second half of an anonymous fetch over HTTP/2, and the git that ships with Debian 12 — version 2.39, built against libcurl 7.88 — now gets a `401` back for a request that had always been allowed. Git reads any `401` as *credentials, please* and asks for a username, which is why typing one never helped and why a token would not have helped either. The update script now asks git to speak HTTP/1.1 for its pull, which GitHub still answers exactly as before, and it no longer waits on the keyboard when a fetch genuinely does fail — it reports the error and stops, instead of leaving an unattended update hanging indefinitely. If you are stuck on an older copy and so cannot update to pick this up, run `git config --global http.version HTTP/1.1` once on the server and `mcupdate` will go through.
+
 - **The same routing path can no longer be added to a contact twice.** Both path editors — the one in a contact's info panel and the one under **My Repeaters → Paths** — took whatever they were given, so an identical route could end up in the list two or three times: added by hand, picked again from the repeater picker, or imported a second time from the device, which is the easiest of the three to do by accident because the button gives no hint that the path is already there. A duplicate is worse than untidy, because the list is a retry order: when a message fails, the app works down it, and a repeated entry simply retries a route that has just been shown not to work while the genuinely different alternative below it waits its turn. Adding a route that is already on the list is now refused with *This path is already on the list*, and the entry box stays open so the hops can be corrected. Two paths count as the same only when both the hops and the hash size match — the same bytes read as 1-byte hops describe a different route than as 3-byte hops, and both remain available. Duplicates already sitting in the list are collapsed into one when you update, keeping the starred copy if one of them was starred.
 
 ---

scripts/update.sh

@@ -40,7 +40,13 @@ echo ""
 
 # Step 1: Git pull
 info "Pulling latest changes from Git..."
-if git pull; then
+# Force HTTP/1.1 for the pull. GitHub's HTTP/2 edge rejects the anonymous
+# git-upload-pack POST sent by older git/libcurl (e.g. Debian bookworm's
+# git 2.39 + libcurl 7.88) with a 401, which git reports as a credential
+# prompt - "Username for 'https://github.com'" - even on this public repo.
+# GIT_TERMINAL_PROMPT=0 turns any auth failure into an error instead of
+# leaving the script waiting on stdin forever.
+if GIT_TERMINAL_PROMPT=0 git -c http.version=HTTP/1.1 pull; then
     success "Git pull completed"
 else
     error "Git pull failed"