Function git_writes_crlf 

pub fn git_writes_crlf(autocrlf: Option<&str>, core_eol: Option<&str>) -> bool

Whether git would write CRLF into the working tree for a path it converts itself.

Git’s text_eol_is_crlf: core.autocrlf first, core.eol only while it is false, the platform when neither says anything. It is asked about a different subject than resolve_output — not “what should we write” but “is git about to expand LF to CRLF in bytes it hands us” — and since 2026-08-11 the two answers differ in one row, so it computes its own rather than borrowing. With core.eol unset git’s default is native, and a path some foreign line declared text really does get expanded; reading our own narrower answer here would have made this say “git left it alone” about a checkout that had just eaten the CR bytes out of a ciphertext, which is the one question this function exists to answer.

That question only comes up on the smudge path, and only once an authentication tag has already failed. Git’s check-out order is blob, then git’s conversion, then smudge, so on a path some attribute line pulled out from under the managed -text, the tag is handed bytes that were never stored — and the file is fine while the message says it is not.