From bf7ff3025a6f0f867e345e9cd16e370a7e376173 Mon Sep 17 00:00:00 2001
From: Claude <noreply@anthropic.com>
Date: Fri, 25 Sep 2026 18:54:00 +0000
Subject: [PATCH] Say which remote to pull from, because git will not
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The server's main tracks gitea/main while new work lands on a branch on
GitHub, so a bare `git pull` asks Gitea, finds it level, and answers
"Already up to date." That sentence is true about the wrong remote and
reads exactly like there is nothing to fetch — which is how the last
deploy stalled on a script that had never arrived.

Step 8 now names a `github` remote beside `gitea`, and the update recipe
in 11.3 pulls from it by name with --no-edit, pushes to gitea, then
rebuilds. 11.3 previously said plain `git pull`, as though the server
tracked GitHub.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NizVpJ2dwzCbjCrTLCjeHn
---
 docs/server-setup.md | 31 ++++++++++++++++++++++++++++---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/docs/server-setup.md b/docs/server-setup.md
index f2f1e9a..4c0a378 100644
--- a/docs/server-setup.md
+++ b/docs/server-setup.md
@@ -193,9 +193,16 @@ your laptop):
 cd ~/vienalatina
 git remote add gitea https://git.vienalatina.com/pablo/vienalatina.git
 git push gitea main
+
+# Name the GitHub remote too, while you are here. The clone in step 5 called it
+# `origin`, but `main` came to track `gitea/main` — so a bare `git pull` asks
+# Gitea, and new work arrives on GitHub. Having both named saves you from typing
+# the URL every time you deploy.
+git remote add github https://github.com/pablovolenski/vienalatina.git
+git remote -v
 ```
 
-(It will ask for your Gitea username/password.)
+(Gitea will ask for your Gitea username/password.)
 
 In Woodpecker (**https://ci.vienalatina.com**):
 
@@ -381,14 +388,32 @@ nothing that is running, and neither does `docker compose up -d
 reports success and the server behaves exactly as it did before, which is the
 most expensive kind of nothing.
 
-An update is a rebuild:
+**And `git pull` on its own will not fetch it.** This is worth knowing before
+it costs you an afternoon: `main` on the server tracks `gitea/main`, while new
+work is pushed to a branch on **GitHub**. So a bare `git pull` asks Gitea,
+finds Gitea level with your local `main`, and answers *"Already up to date."* —
+which is true about the wrong remote, and reads exactly like there is nothing
+to do.
+
+An update is a named pull, a push to Gitea so the build pipeline sees it, and a
+rebuild:
 
 ```sh
 cd ~/vienalatina
-git pull
+git pull --no-edit github <the-branch-name>   # e.g. claude/relaxed-faraday-h4zd09
+git push gitea main
 sudo bash scripts/deploy-board.sh
 ```
 
+`--no-edit` accepts the default merge message. Without it git opens an editor,
+which is a strange place to find yourself mid-deploy.
+
+If `github` is not a remote yet, add it once — see the end of step 8:
+
+```sh
+git remote add github https://github.com/pablovolenski/vienalatina.git
+```
+
 That rebuilds the image, copies the compose file across, restarts, and prints
 the log. It never touches `/srv/board/.env` — that file holds the secrets and
 lives only on the server — but it does compare it against `.env.example` and