fix(core): detect mixed line endings instead of flagging CRLF on a single match

[shoemoney]

Summary

detectLineEnding() in packages/core/src/utils/textUtils.ts classifies a
file as CRLF if it contains even one \r\n anywhere in the content, no
matter how many plain LF lines surround it:

export function detectLineEnding(content: string): '\r\n' | '\n' {
  return content.includes('\r\n') ? '\r\n' : '\n';
}

Both edit.ts and write-file.ts use that single verdict to decide whether
to rewrite every line ending in the whole file on write (edit.ts line
~937: const useCRLF = (!editData.isNewFile && editData.originalLineEnding === '\r\n') || ..., followed by finalContent.replace(/\r?\n/g, '\r\n')).

Concretely: a file with 99 LF lines and one stray CRLF line (a pasted
Windows snippet, or a partial line-ending conversion someone missed) gets
classified as a CRLF file. The next time an unrelated single-line edit
touches that file, every LF line is silently rewritten to CRLF - a 1-line
intended change turns into a 100-line diff, with nothing telling you it
happened.

Details

Made detection purity-based: '\r\n' is only returned when CRLF is the
only newline style present in the content.

export function detectLineEnding(content: string): '\r\n' | '\n' {
  const crlfCount = (content.match(/\r\n/g) || []).length;
  const totalNewlines = (content.match(/\n/g) || []).length;
  return totalNewlines > 0 && crlfCount === totalNewlines ? '\r\n' : '\n';
}

I did not touch edit.ts or write-file.ts. Both call useCRLF with no
else branch - when it's false the content is written through unmodified.
So '\n' is already the safe, non-destructive verdict; this change only
affects which files get classified that way. A file that's actually pure
CRLF still round-trips as CRLF (no regression to the existing behavior
that PR #16087 added).

This is a residual gap in the fix from #16087 / issue #9604, which added
detectLineEnding in the first place to stop line endings from being
"unpredictably converted." It didn't cover mixed-EOL files. I'm not
claiming to fix #9604 or #16087 - just closing a gap they left open.

The existing line-endings.test.ts only had pure-CRLF and pure-LF
fixtures, which is exactly why this passed CI. I added:

• a mostly-LF file with one stray CRLF is now classified as LF
• a pure-CRLF file still round-trips as CRLF (no regression)
• an end-to-end test through EditTool: editing one line in a
  mostly-LF file that has a stray CRLF line no longer forces the whole
  file to CRLF

Related Issues

Related to #9604 (not fixing it directly - that issue covers the broader
"line endings unpredictably converted" problem; this closes one specific
gap in the detectLineEnding heuristic that #16087 introduced).

How to Validate

From packages/core:

npx vitest run src/tools/line-endings.test.ts

To see the bug reproduce, revert the change in textUtils.ts only (keep
the new tests) and rerun - two tests fail, and the failing edit-path test
shows the whole file getting rewritten to CRLF:

expected 'line1\r\nline2\r\nline3\r\nmodified\r\n' to be 'line1\nline2\nline3\nmodified\n'

I ran the fix through this cycle (tests red against unpatched code, green
against the fix, red again after reverting the fix) before opening this PR.

I also ran the broader adjacent suite to check for regressions:

npx vitest run src/utils/textUtils.test.ts src/tools/edit.test.ts src/tools/write-file.test.ts src/tools/line-endings.test.ts

All 169 tests pass. Also ran eslint and prettier --check on both
changed files, clean.

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[github-actions]

📊 PR Size: size/M

• Lines changed: 88
• Additions: +84
• Deletions: -4
• Files changed: 2

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where the line ending detection logic was overly aggressive, causing files with mixed line endings to be incorrectly classified as CRLF. By refining the detection heuristic to require purity, the system now avoids unnecessary and destructive wholesale rewriting of line endings during minor file edits, improving the reliability of file modifications.

Highlights

• Improved Line Ending Detection: Updated the detectLineEnding utility to use a purity-based heuristic, ensuring files are only classified as CRLF if they exclusively contain CRLF line endings.
• Prevention of Unintended Line Ending Conversion: Prevented files with mixed line endings (e.g., mostly LF with a single stray CRLF) from being incorrectly identified as CRLF, which previously caused unrelated edits to silently rewrite the entire file's line endings.
• Enhanced Test Coverage: Added new test cases to verify correct handling of mixed-EOL files and confirmed that pure CRLF files continue to be correctly identified.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the line ending detection logic in detectLineEnding to ensure that files with mixed line endings (e.g., mostly LF with a single stray CRLF) are classified as LF rather than CRLF, preventing unintended wholesale conversions during edits. It also adds comprehensive tests to verify this behavior. The reviewer suggested an excellent performance optimization to replace the double string scanning and array allocations with a single regex test using a negative lookbehind assertion.

[gemini-code-assist]

Using content.match(/\r\n/g) and content.match(/\n/g) scans the entire string twice and allocates two arrays containing all matches. For large files, this can lead to significant memory overhead and garbage collection pressure.

We can optimize this to $O(N)$ time and $O(1)$ space with zero allocations by checking if the content contains \n and does not contain any \n that is not preceded by \r (using a negative lookbehind assertion (?<!\r)\n). Since Node.js >= 20 is used, lookbehind assertions are fully supported.

Suggested change

	const crlfCount = (content.match(/\r\n/g) || []).length;
	const totalNewlines = (content.match(/\n/g) || []).length;
	return totalNewlines > 0 && crlfCount === totalNewlines ? '\r\n' : '\n';
	return content.includes('\n') && !/(?<!\r)\n/.test(content) ? '\r\n' : '\n';

[shoemoney]

Good catch, took the suggestion as written. Pushed in decad6b.

Checked equivalence with the counting version across the cases that matter: pure CRLF -> '\r\n', pure LF -> '\n', mixed (any lone \n) -> '\n', empty/no-newline -> '\n'. Also checked a lone-CR input (old-Mac \r with no \n at all) since the lookbehind reads differently from a naive glance at the counting code - that one falls through the includes('\n') check and returns '\n', same as before. Added a unit test for it.

Reran the same red/green/red cycle from the PR description against this change: the two regression tests in line-endings.test.ts still fail if you revert just textUtils.ts back to the pre-fix content.includes('\r\n') heuristic, and pass with either the counting version or this one. Full suite (textUtils.test.ts, edit.test.ts, write-file.test.ts, line-endings.test.ts) is 170/170 now (169 + the new lone-CR case). eslint/prettier clean.

[Hardanish-Singh]

+1 to bot comments

[gemini-cli]

Hi there! Thank you for your interest in contributing to Gemini CLI.

To ensure we maintain high code quality and focus on our prioritized roadmap, we only guarantee review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'.

This PR will be closed in 7 days if it remains without that designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding.