.gitattributes

# Windows shell entry points must reach the user with CRLF line endings.
#
# install.cmd is documented as a `curl -O` download from raw.githubusercontent.com,
# which serves the stored blob byte for byte — no checkout-time eol conversion ever
# runs. `-text` keeps git from normalising the CRLF out of the blob, so the file a
# user downloads is the file cmd.exe was designed to read. (LF-only batch files are
# a known source of failures around labels and multi-line blocks.)
*.cmd -text
*.bat -text

# The Epic 19 BI corpus is RFC-4180 with newlines INSIDE quoted fields: 7 of its 99
# captured statements span several physical lines, which is why the file is 126 lines
# for 99 records. Checkout-time eol conversion rewrites the byte stream wholesale, so
# on a clone with `core.autocrlf=true` it would insert CR into the STATEMENTS
# themselves — feeding the parser a shape no BI tool ever emitted, breaking the
# byte-for-byte equality with the capture artefact that story 21.6 asserts, and doing
# it invisibly because macOS/Linux CI never reproduces it. `-text` keeps the stored
# bytes byte for byte on every platform. Applies to the replay's baseline and
# attribution tables too: they are the same gate's tracked inputs — and to the live
# Tableau corpus beside them, whose statements carry literal TAB characters and are
# replayed through the same parser by the same kind of gate.
sql/src/test/resources/corpus/*.csv -text

# documentation/sql/keywords.md is compared BYTE FOR BYTE against freshly generated output by
# `KeywordsPageSpec`. Checkout-time eol conversion would rewrite the whole file on a clone with
# `core.autocrlf=true`, while the generator emits LF, so the guard would redden for the platform
# rather than for the content - invisibly, since macOS/Linux CI never reproduces it. `-text` keeps
# the stored bytes byte for byte everywhere.
documentation/sql/keywords.md -text