Nobody Declared the Line Endings, and a Generator Never Converged

A code generator in my workspace judged its own output stale on every run and rewrote it. The repository carried no .gitattributes at all, so every text file took its line endings from whatever core.autocrlf the clone had. Mine was a Windows clone that inherited core.autocrlf=true from the system config, and nearly every text file came out CRLF. The generator brackets its managed block with sentinel comments, extracts the current block with awk, and compares it byte for byte against its template with cmp. Git for Windows ships an awk that opens files in text mode and drops the carriage return, so the extracted block came out LF while the template it was measured against stayed CRLF. The two could never compare equal, every run judged the block stale, and the rewrite put back the same CRLF block for the next run to reject.

The fix was one file, and it changed no line of the generator. Git's documentation is explicit that core.autocrlf and core.eol decide line endings only where the attributes do not, and no attribute covered the template. The first fix, half an hour earlier, had been for a different generator that baked a stray carriage return into its output. It pinned three paths: the one that broke, and two more pinned pre-emptively. The template this generator compared against was in none of them. The second fix put a repo-wide * text=auto eol=lf above that list and kept the three lines beneath it. None of the affected files had ever been committed carrying a carriage return, so the damage only existed on disk. A path list can only name what someone already had in mind, and the thing that breaks next is the one it could not have named.