Problem
tracked() in .github/actions/repo-gate/repo_gate.py reads git ls-files and depends on git's own quoting to keep that output ASCII, without pinning the setting that quoting comes from and without a handler if it does not. sh() has the same shape. #1574 fixed the sibling defect in prose_lint.py by pinning core.quotePath=true and decoding the escape, and left this gate as it was.
Two symptoms, one cause.
It crashes. With core.quotePath=false set in the repository or the host's git config, ls-files emits the path bytes raw. The strict decode raises UnicodeDecodeError, which is a ValueError and so is caught by neither handler around the call, and the gate ends in a traceback rather than a verdict.
It silently drops a file from coverage. At the default setting the quoting is on, so tracked() yields the escaped spelling rather than the name on disk. (root / rel).is_file() is then false for that entry, and check_eol passes over the file without reporting anything. A tracked file whose name holds a non-ASCII character is therefore never checked, and the gate reports clean.
Evidence
Constructed: a repository holding one tracked text file whose name contains a byte that is not valid UTF-8.
core.quotePath=false UnicodeDecodeError out of tracked(), no verdict
core.quotePath=true tracked() yields the escaped spelling
resolved_eol on that spelling -> eol: unspecified
resolved_eol on the real name -> eol: lf
check_eol skips the file, gate reports clean
Confirmed present at a3cd9c7, so this is not a regression from #1574.
Suggested fix
The same shape #1574 settled next door: pin core.quotePath=true on the invocation so the escaped form is the only form, and decode the escape into the real name. prose_lint.py's diff_header_path is the working reference, including its note that turning the quoting off instead covers only one of the three routes by which git quotes a name.
Related: #1575 and #1576, the two other false cleans of this class found in the same review.
Found by a local review pass while fixing #1538 in #1574.
Problem
tracked()in.github/actions/repo-gate/repo_gate.pyreadsgit ls-filesand depends on git's own quoting to keep that output ASCII, without pinning the setting that quoting comes from and without a handler if it does not.sh()has the same shape. #1574 fixed the sibling defect inprose_lint.pyby pinningcore.quotePath=trueand decoding the escape, and left this gate as it was.Two symptoms, one cause.
It crashes. With
core.quotePath=falseset in the repository or the host's git config,ls-filesemits the path bytes raw. The strict decode raisesUnicodeDecodeError, which is aValueErrorand so is caught by neither handler around the call, and the gate ends in a traceback rather than a verdict.It silently drops a file from coverage. At the default setting the quoting is on, so
tracked()yields the escaped spelling rather than the name on disk.(root / rel).is_file()is then false for that entry, andcheck_eolpasses over the file without reporting anything. A tracked file whose name holds a non-ASCII character is therefore never checked, and the gate reports clean.Evidence
Constructed: a repository holding one tracked text file whose name contains a byte that is not valid UTF-8.
Confirmed present at
a3cd9c7, so this is not a regression from #1574.Suggested fix
The same shape #1574 settled next door: pin
core.quotePath=trueon the invocation so the escaped form is the only form, and decode the escape into the real name.prose_lint.py'sdiff_header_pathis the working reference, including its note that turning the quoting off instead covers only one of the three routes by which git quotes a name.Related: #1575 and #1576, the two other false cleans of this class found in the same review.
Found by a local review pass while fixing #1538 in #1574.