Signierskript: ein Klon von vor dem Rewrite darf nicht pullen

Am 07.09.2026 sind drei Commits am Ende von main entfernt und der Branch per
Force-Push zurueckgesetzt worden. Ein aelterer Klon - der Mac, auf dem
signiert wird - steht damit VORAUS statt zurueck. Der Waechter sagte dort
"Erst 'git pull' ausfuehren", und genau das ist die Falle: der Merge holt die
entfernten Commits zurueck in die Historie, der naechste Push stellt sie auf
dem Server wieder her, und zwar ohne --force.

Git kann diese Lage nicht von echter ungepushter Arbeit unterscheiden. Das
Skript entscheidet deshalb nicht, sondern listet die nur lokal vorhandenen
Commits auf, nennt beide Moeglichkeiten samt richtigem Befehl und bricht ab.
Nur der schlichte Rueckstand empfiehlt weiterhin 'git pull'.

Beide Zweige gegen Wegwerf-Repos in der jeweiligen Form geprueft, nicht nur
geparst - die erste Fassung stufte die Lage als "auseinandergelaufen" ein und
haette dem Mac zum Pushen geraten.

APPLE_DEV_BACKLOG.md nennt den einmaligen Schritt im Abschnitt "Vorher".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-09-07 20:58:05 +02:00
parent 0e84248d38
commit 185a044c5e
3 changed files with 50 additions and 1 deletions
+15
View File
@@ -59,6 +59,21 @@ Nichts vorzubereiten außer einem aktuellen Stand:
git pull
```
> **Einmalig, für jeden Klon von vor dem 07.09.2026:** an diesem Tag sind drei
> Commits am Ende von `main` entfernt und der Branch per Force-Push
> zurückgesetzt worden. Ein älterer Klon steht damit **vor** `origin/main` und
> `git pull` ist dort das Falsche — es würde die entfernten Commits per Merge
> zurückholen, und der nächste Push stellte sie auf dem Server wieder her (er
> ginge sogar ohne `--force` durch). Richtig ist einmalig:
>
> ```bash
> git fetch origin && git reset --hard origin/main
> ```
>
> Das Skript erkennt die Lage selbst, listet die betroffenen Commits auf und
> bricht ab, statt zu raten — es entscheidet aber nicht für dich, weil dieselbe
> Lage auch echte ungepushte Arbeit sein kann.
Das Skript prüft das selbst und **bricht ab**, wenn der Arbeitsbaum nicht sauber
oder `HEAD` nicht gleich `origin/main` ist - sonst signierte es einen veralteten
Stand. Ebenso bricht es ab, wenn das Zielgerät nicht im Team eingetragen ist