# Shell scripts in here are SHIPPED ARTIFACTS, and they are executed by a Linux kernel that has no
# opinions about where they were edited. build-portmaster.sh copies PocketTracker.sh into the zip
# byte-for-byte, so whatever the checkout put in the working tree is what the handheld runs.
#
# This dev box has core.autocrlf=true. Without this file, committing a launch script written with LF
# and checking it back out hands the device CRLF — and a CFW answers a CRLF shebang with
#
#     /bin/bash^M: bad interpreter: No such file or directory
#
# i.e. the port does not start at all, and the log says nothing a user could act on. The failure
# arrives one clone later than the mistake, on someone else's machine, which is what makes it worth
# a file. (Same rule and same reasoning as tools/testdata/.gitattributes and native/songcore's: EOL
# conversion follows the ARTIFACT, not the directory.)
*.sh text eol=lf

# The container recipe is read by docker on Linux; a CRLF in a RUN line ends up inside the command.
Dockerfile.portmaster text eol=lf

# ⚠️ THE REST OF THE PACKAGE IS AN ARTIFACT TOO, AND THE RULE ABOVE DOES NOT CARE THAT THESE PARSE
# EITHER WAY. `port.json`, `gameinfo.xml` and the shipped README are copied into the zip byte-for-byte
# exactly as PocketTracker.sh is, and they were left `unspecified` — so the bytes a handheld receives
# depended on which OS ran `git clone`. Nothing breaks today (XML normalises \r\n, and JSON calls it
# whitespace), which is the only reason it went unnoticed; it is pinned because "an artifact whose
# contents vary by the porter's OS" is the same bug as the shebang, caught before rather than after.
portmaster/*.json text eol=lf
portmaster/*.xml  text eol=lf
portmaster/*.md   text eol=lf

# The same rule pointing the other way, which is the point of stating it as "EOL follows the
# ARTIFACT" rather than "this repo uses LF". README.txt is copied into the WINDOWS zip and opened by
# a Windows user in Notepad, so CRLF is what it should contain — pinned here so it does not depend
# on which OS ran `git clone`, exactly as the PortMaster files above do not.
windows/*.txt text eol=crlf

# ⚠️ The icon is BINARY and must never be EOL-converted. It is committed (make-icon.ps1 regenerates
# it but no build runs that), and with core.autocrlf=true on this box an unmarked .ico would have
# every 0x0A in its pixel data rewritten to 0x0D 0x0A on checkout — a corrupt icon, on someone
# else's clone, from a setting nobody touched. `git check-attr binary -- shell/windows/*.ico`
# answers this rather than the file extension being trusted to be recognised.
windows/*.ico binary
