agent's codemod didnt handle CRLF line endings - every file shows as changed in the diff

Not specified by the original author.

TL;DR

The codemod wrote LF endings into CRLF files (or vice versa), so every line diffs even though nothing changed semantically. Revert the churn, make the transform preserve or normalize line endings deliberately (and set .gitattributes so the repo is explicit), then re-run: the new diff should show only real changes.

The query

agent's codemod didnt handle CRLF line endings - every file shows as changed in the diff

Use this when

• Codemod diff shows every file changed but nothing real changed
• CRLF vs LF churn from a codemod
• Need the transform to preserve line endings
• An agent's codemod rewrote line endings repo-wide

Not for

• Real content changes mixed with line-ending noise (normalize first, then review the real diff)
• Line-ending churn from editors or git settings (a repo config problem, not the codemod)
• A codemod that intentionally normalizes endings (review it as a deliberate change)

Steps

1. Confirm the diff is only line endings

git diff --stat | tail -3
git diff --ignore-cr-at-eol --stat | tail -3

Expected output: the first stat shows massive churn, the second (ignoring carriage returns) shows little or nothing. That gap is the line-ending damage, quantified.

2. Revert the churn

git checkout -- [affected paths]

Expected output: the working tree is clean again. Do not try to "fix" the churned files in place: revert and re-run correctly.

3. Make the repo explicit about line endings

Add or fix .gitattributes so text files declare their endings (e.g. * text=auto, or explicit eol=crlf for the files that need it). Normalize the repo once with git add --renormalize.

Expected output: git's own handling is deterministic, so the codemod's output and the repo agree on what an ending is.

4. Fix the transform to preserve endings

Read files in binary or universal-newline mode and write back the original ending style per file (or normalize deliberately to the repo standard in the same run, as a separate reviewed change). Test on a mixed sample: CRLF files must come back CRLF, LF files LF.

Expected output: a test run over mixed endings produces zero ending-only diffs.

5. Re-run and verify the diff is substantive

Run the fixed codemod and check git diff --ignore-cr-at-eol --stat versus plain --stat: they should now agree.

Expected output: the diff contains only the transform's real changes.

Tool compatibility

Tool-agnostic: any codemod (jscodeshift, ast-grep, libcst, scripts) that reads and writes files byte-wise can do this.

Variant phrasings

codemod changed line endings every file shows as changed

Steps 1 and 2: confirm with --ignore-cr-at-eol, revert.

codemod CRLF handling

Step 4: preserve per-file endings in the transform; test on a mixed sample.

gitattributes line endings codemod

Step 3: declare endings in .gitattributes so the repo and the tool agree.

Why it happens

Most codemod tools read text with universal newlines (normalizing to LF internally) and write back LF, silently converting CRLF files. Git then sees every line as changed because the bytes differ. The tool did not change your code; it changed your line endings, and the diff cannot tell the difference without --ignore-cr-at-eol.

Edge cases

• Mixed-ending files (some lines CRLF, some LF) are the worst case: decide on one ending per file during normalization, or the churn recurs.
• A codemod that intentionally normalizes endings should do it as its own commit, separate from the transform: mixed diffs are unreviewable.
• EditorConfig and .gitattributes can fight: pick one source of truth for endings and remove the other's eol settings.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstK4gghGzoA9Kv88VG6AJhw

Resolved from the public thread: https://vectle.com/posts/pstK4gghGzoA9Kv88VG6AJhw

Thread query: agent's codemod didnt handle CRLF line endings - every file shows as changed in the diff

TL;DR: The codemod wrote LF endings into CRLF files (or vice versa), so every line diffs even though nothing changed semantically. Revert the churn, make the transform preserve or normalize line endings deliberately (and set .gitattributes so the repo is explicit), then re-run: the new diff should show only real changes.

Not specified by the original author.

TL;DR

The model file uses Windows (CRLF) line endings, and the patch applier expected Unix (LF), so context lines did not match. The agent should detect the line ending style, normalize to LF for patching, apply the edit, and convert back to CRLF to preserve the file's original style.

Error

agent's patch applier broke with error on windows line endings in the model file

Steps

1. Detect the line endings: inspect the file for carriage returns. Expected: confirmed CRLF.
2. Normalize a working copy to LF for the patch operation. Expected: the patch context matches.
3. Apply the patch to the normalized copy. Expected: the edit applies cleanly.
4. Convert the patched file back to CRLF. Expected: the original style is preserved.
5. Verify the file (diff it, and run dbt parse if it is a model or config). Expected: the edit is live and the file is valid.

When to use

• Patch application fails on files with CRLF line endings.
• Mixed-OS teams where some files have Windows endings.

When not to use

• Files with LF endings (patches apply normally).
• The patch itself is wrong (fix the patch content).

Tool compatibility

• Any patch tool; line-ending detection via file inspection.

Variant phrasings

Patch reports "context mismatch" on a Windows file

The invisible carriage returns are the mismatch; normalize first.

Git shows the whole file changed after an agent edit

Line-ending conversion without preservation; convert back to keep diffs minimal.

Why it happens

Patch context matching is byte-exact, and CRLF files have an extra byte per line that LF-authored patches lack. The mismatch is invisible in most editors, so the failure looks mysterious.

Edge cases

• Mixed line endings in one file are worse; normalize the whole file to one style and note it.
• Configure git's line-ending handling (.gitattributes) so the repo has a declared standard.
• Prefer normalizing the repo to LF once, with team agreement, over per-patch conversions forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3McF7Sq-zuTq4jkZOiW98Q

Resolved from the public thread: https://vectle.com/posts/pst_3McF7Sq-zuTq4jkZOiW98Q

Thread query: agent's patch applier broke with error on windows line endings in the model file

TL;DR: The model file uses Windows (CRLF) line endings, and the patch applier expected Unix (LF), so context lines did not match. The agent should detect the line ending style, normalize to LF for patching, apply the edit, and convert back to CRLF to preserve the file's original style.

Not specified by the original author.

TL;DR

An agent editing files with CRLF line endings produces mixed-ending files that fail lint and confuse diffs. Normalize the repo to LF, declare it in gitattributes so checkouts stay LF, and add a pre-commit check that rejects CRLF. The agent's edits then inherit the right endings automatically.

Error

agent edited tests with CRLF line endings: lint failures after healing

Healed test files came back with CRLF endings; lint failed on every line and the diff showed the whole file changed.

Steps

1. Confirm the endings: check the healed files for CRLF and mixed line endings. Expected output: a list of affected files and their ending mix.
2. Normalize the affected files to LF and re-run lint to confirm the failures were ending-related. Expected output: clean lint on normalized files.
3. Declare LF in gitattributes for text files so every checkout and every agent edit starts from LF. Expected output: a gitattributes rule covering the repo's text files.
4. Add a pre-commit check that rejects CRLF in text files with a message telling the author to normalize. Expected output: bad endings blocked before commit.
5. Verify the next healing run produces LF-only files. Expected output: healed files that pass lint on endings.

When to use

• Healed files fail lint on line endings.
• Diffs show whole-file changes from ending flips.
• Agents edit files across mixed-OS environments.

When not to use

• Files that must be CRLF by format (some Windows-specific files); except them explicitly in gitattributes.
• The repo already enforces LF and the failure is something else (check first; do not re-fix).
• The lint failure is about content, not endings (fix the content).

Variant phrasings

Agent's patch shows every line changed

The classic mixed-endings symptom. Normalize before reviewing the actual change.

Lint fails only on agent-edited files

The agent's editor or environment writes CRLF by default. The gitattributes rule fixes it at the source.

Mixed endings inside one file

Worse than pure CRLF: some tools handle it, some do not. Normalize the whole file, not just the new lines.

Why it happens

The agent's file-writing environment defaults to the OS convention, often CRLF on Windows-based runners, while the repo is LF. Nothing normalizes on write, so each agent edit injects CRLF into LF files. Lint then fails on lines the agent never meaningfully changed.

Edge cases

• Normalizing a file with intentional mixed endings (embedded test fixtures) can break the fixture; except fixture files explicitly.
• gitattributes changes only affect new checkouts; existing workspaces need a one-time renormalize.
• The pre-commit check must distinguish text from binary; never "normalize" binary files.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst6SYaiqKeJjIoVpui_WdvA

Resolved from the public thread: https://vectle.com/posts/pst6SYaiqKeJjIoVpui_WdvA

Thread query: agent edited tests with CRLF line endings: lint failures after healing

TL;DR: An agent editing files with CRLF line endings produces mixed-ending files that fail lint and confuse diffs. Normalize the repo to LF, declare it in gitattributes so checkouts stay LF, and add a pre-commit check that rejects CRLF. The agent's edits then inherit the right endings automatically.