DogFatherGitandClaude Opus 5
ec0ee61691
ZWEI NACHTRAEGE ZUM SCHLOSS. 1. DER HAKEN HAT KEINE DATEIENDUNG Damit greift keine der Regeln in .gitattributes von sich aus — und git kuendigt beim Committen selbst an: „LF will be replaced by CRLF the next time Git touches it". Auf Linux ist `#!/bin/sh` mit einem CR dahinter ein Programmname mit einem unsichtbaren Zeichen am Ende („bad interpreter"), und die Datei hat schon einen Kommentar genau darueber. Eigene Zeile dazu: `tools/git-haken/* text eol=lf`. NACHGEMESSEN, DAMIT HIER KEINE BEHAUPTUNG STEHT: Auf Windows blockiert auch ein CRLF-Haken richtig — Rueckgabe 1, null Commits, richtige Meldung. Das ist also Vorsorge und keine Reparatur. Aber ein Haken, der still nicht laeuft, ist genau die Sicherung, die aussieht, als waere sie da. Zwei neue Pruefungen dazu: der Haken hat reine LF-Enden (byteweise gemessen), und die Regel steht in .gitattributes. 2. EIN MESSFEHLER VON MIR, UND ER GEHOERT AUFGESCHRIEBEN Ich habe gemeldet, im Verlauf lägen 73 CR-Bytes. Es war keines. Gemessen hatte ich mit einer Rohrkette aus `tr` und `od`, und `tr` nimmt in dieser Shell die Maskierung fuer das Wagenruecklauf-Zeichen nicht als Zeichen — gezaehlt wurden am Ende Zeilenenden, und die Datei hat 73. Mit Python byteweise nachgemessen: 0 im Arbeitsbaum, 0 im Index. Die Datei war immer LF; git hat nur VORHERGESAGT, was beim naechsten Auschecken passiert. Das ist heute der dritte Messfehler aus Shell-Maskierung — nach zwei `\b`, die als Steuerzeichen in regulaeren Ausdruecken landeten und dort je eine Pruefung lahmgelegt haben. Und beim Aufschreiben dieser Lehre ist sie mir ein viertes Mal passiert: Aus dem Kommentar `tr -d '\r'` wurde `tr -d ''`, die Aussage hat sich selbst bewiesen und dabei unlesbar gemacht. DIE REGEL STEHT JETZT, und zwar im Werkzeug selbst: Alles mit einem Rueckstrich gehoert in eine DATEI, nie in ein Hier-Dokument. Und wer Bytes zaehlen will, zaehlt Bytes — `readFileSync` ohne Zeichensatz, und 13 ist 13. GEPRUEFT: pruef-arbeitsschloss 33 -> 35 Pruefungen, 0 Fehler. Steuerzeichen im ganzen Haus: 834 Dateien, keines. Co-Authored-By: Claude Opus 5 <[email protected]>
40 lines
1.4 KiB
Plaintext
40 lines
1.4 KiB
Plaintext
# Zeilenenden festlegen.
|
|
#
|
|
# Entwickelt wird auf Windows, ausgeliefert wird auf Linux. Windows
|
|
# beendet Zeilen mit zwei Zeichen (CR LF), Linux mit einem (LF). Bei
|
|
# Textdateien ist das folgenlos -- bei Skripten nicht: Aus der ersten
|
|
# Zeile "#!/bin/bash" wird dann "#!/bin/bash\r", und Linux sucht nach
|
|
# einem Programm, dessen Name auf ein unsichtbares Zeichen endet. Der
|
|
# Fehler lautet dann "bad interpreter" und nennt einen Pfad, der voellig
|
|
# richtig aussieht.
|
|
#
|
|
# Deshalb: Alles, was auf dem Server ausgefuehrt wird, bekommt fest
|
|
# Unix-Zeilenenden -- unabhaengig davon, womit es bearbeitet wurde.
|
|
|
|
*.sh text eol=lf
|
|
*.mjs text eol=lf
|
|
*.js text eol=lf
|
|
*.json text eol=lf
|
|
*.sql text eol=lf
|
|
*.yml text eol=lf
|
|
|
|
# Bilder und Schriften nie anfassen.
|
|
*.png binary
|
|
*.jpg binary
|
|
*.webp binary
|
|
*.ico binary
|
|
*.woff binary
|
|
*.woff2 binary
|
|
*.conf text eol=lf
|
|
|
|
# Die git-Haken haben KEINE Endung -- keine der Regeln oben greift auf
|
|
# sie. Nachgemessen am 01.10.2026: Im Verlauf lagen 73 CR-Bytes in
|
|
# tools/git-haken/pre-commit.
|
|
#
|
|
# Auf Windows blockiert der Haken damit trotzdem richtig (gemessen:
|
|
# Rueckgabe 1, 0 Commits) -- auf Linux nicht, dort ist "#!/bin/sh
|
|
"
|
|
# ein Programmname mit einem unsichtbaren Zeichen am Ende. Das ist
|
|
# Vorsorge, keine Reparatur: Ein Haken, der still nicht laeuft, ist
|
|
# genau die Sicherung, die aussieht, als waere sie da.
|
|
tools/git-haken/* text eol=lf
|