.gitattributes

# Zeilenenden — die Datei existiert wegen des WSL-Pfads.
#
# Das Kit besteht aus Shell-Skripten, die unter Windows regelmäßig mit Git for
# Windows geklont werden. Dort ist `core.autocrlf=true` der Auslieferungswert:
# Der Klon landet mit CRLF im Arbeitsbaum, und die erste Zeile jedes Skripts
# wird zu `#!/usr/bin/env bash\r`. Bash sucht dann einen Interpreter, der
# buchstäblich `bash\r` heißt, und meldet
#
#     bash: ./vollautomatik.sh: /usr/bin/env: bad interpreter: No such file or directory
#
# — ein Fehlerbild, das nach einer kaputten Installation aussieht und keines
# ist. `eol=lf` erzwingt LF im Arbeitsbaum unabhängig von der Git-Konfiguration
# der Maschine; damit ist der Fall nicht mehr dokumentiert, sondern erledigt.
* text=auto eol=lf

# Ausnahme für die pwsh-Bahn: Batch-Dateien brauchen CRLF.
#
# `.cmd`/`.bat` werden vom Kommandozeileninterpreter zeilenweise gelesen, und
# zwar während der Ausführung. Bei reinem LF verhalten sich `goto`, Labels und
# mehrzeilige Blöcke unzuverlässig — mal läuft es, mal springt es ins Leere.
# Das Fehlerbild ist sporadisch und sieht nach einem Logikfehler aus.
#
# `.ps1` und `.psm1` bleiben bewusst bei LF: PowerShell liest die Datei am
# Stück und ist gegen Zeilenenden unempfindlich. Eine Ausnahme ohne Not wäre
# eine zweite Regel, die jemand pflegen müsste.
# Seit der Bahn-Trennung am PFAD statt an der Endung: Eine .cmd kann nur
# unter pwsh/ liegen. Taucht eine ausserhalb auf, greift die Regel NICHT —
# und das ist gewollt, denn dann stimmt die Ablage nicht.
pwsh/**/*.cmd text eol=crlf
pwsh/**/*.bat text eol=crlf

# Nicht hier geregelt, aber hier zu suchen — die KODIERUNG (BL-113):
#
#     pwsh/  (.ps1, .psm1)  ->  UTF-8 MIT BOM
#     bash/, geteilt/       ->  UTF-8 OHNE BOM
#
# Git kennt dafür keine Direktive; das BOM ist Inhalt und steht in den Dateien
# selbst. Durchgesetzt wird die Regel von `geteilt/tests/test_bl113_bom_regel.py`
# und von bash/kit-test.sh, Schritt 10.
#
# Der Grund ist derselbe wie oben: eine Windows-Eigenheit, die unter Linux
# unsichtbar bleibt. Windows PowerShell 5.1 liest eine Datei ohne BOM in der
# ANSI-Codepage statt in UTF-8. Aus dem Geviertstrich `—` wird dabei `â€"`,
# und dessen letztes Zeichen ist U+201D — für PowerShell eine gültige
# Stringgrenze. Jeder Gedankenstrich schließt dann seine Zeichenkette mitten
# im Satz, und die Datei stirbt beim Parsen, bevor irgendein Hinweis greifen
# kann. pwsh 7 liest UTF-8 ohne BOM korrekt; der Fehler ist deshalb nur auf
# dem Ziel sichtbar.

# Binärdateien: nie konvertieren, nie diffen.
*.webp binary
*.png  binary