Line ending differences in a code review: how to fix it

Your code review shows a whole file as changed, even though you only edited a few lines. Or two versions look identical, but the diff is full of red and green. One common cause is line endings: invisible characters that mark where each line ends.

Compare both versions first, then normalize the endings without discarding real edits. The browser-based Text Compare tool can help you check whether the difference is in the text or in how the lines are stored.

Compare the two versions

1. Open Text Compare and put the same section from the original version and your edited version into the two comparison areas.
2. Use enough surrounding lines to make the location clear. Make sure you are comparing the same file and the same section, and do not remove blank lines or spaces while copying.
3. Review the differences. Look for changes across nearly every line, or a large section marked different despite looking the same. Also check whether only a few lines differ as expected.
4. Open each file in your editor and check its line-ending indicator or setting. Many code editors show CRLF or LF in the status bar. If the files use different endings, normalize the edited file to match the repository's convention, then compare again.

Line endings are not normally visible when you read a file. Copying and pasting can also change them, so use the files themselves and your editor's indicators to confirm what is happening.

What the result means

Nearly every line is marked as changed

The versions may use different line endings. Windows commonly uses CRLF, which stores a carriage return and a line feed at each line break. macOS and Linux commonly use LF, a single line-feed character. A text comparison may treat that invisible difference as a change on every line.

Check the line-ending setting in your editor before editing the code. Do not accept a review that replaces the entire file until you have checked whether the change is only line endings.

Only some lines are marked as changed

You may have a real content change, or the file may contain mixed line endings. Some lines could end in CRLF while others end in LF. Check the marked lines and the editor's line-ending indicator, then normalize the whole file if the repository expects one convention.

The lines look the same, but the comparison still differs

Line endings are one possibility, but not the only one. Trailing spaces, tabs, different indentation, or a changed character encoding can also create differences. Check the specific changed lines rather than assuming that all whitespace changes are harmless.

The review becomes smaller after normalization

The broad diff was caused by inconsistent line endings. Review the remaining changes carefully: normalization can remove noise from the review, but it does not confirm that the code itself is correct.

How to fix it

1. Check the repository's convention. Look at nearby files, existing commits, or a .gitattributes file. Match the project's established rule instead of choosing LF or CRLF based only on your operating system.
2. Convert the current file in your editor. In Visual Studio Code, select the CRLF or LF indicator in the status bar, choose the ending used by the project, and save the file. This changes the current file. It is different from choosing a default for files you create later.
3. Set a default for new files. In Visual Studio Code on Windows 11, open File › Preferences › Settings. On macOS, open Code › Settings › Settings. Search for files.eol and set it to the project's line ending, for example \n for LF. This default helps prevent future mismatches, but check existing files separately.
4. Set a shared rule for the repository. Add a .gitattributes file with rules for the file types the project uses. For example, *.js text eol=lf tells Git to use LF for JavaScript files. If a particular type needs CRLF, set that pattern to eol=crlf. Choose patterns that fit your project rather than applying one rule blindly to every file.
5. Renormalize tracked files only when the team agrees. After changing the repository rules, Git can reapply them to tracked files with git add --renormalize .. Do this on a branch, then inspect the staged changes with git diff --cached. Normalizing many files can create a large review, so keep it separate from unrelated code changes when possible.

Git settings such as core.autocrlf can affect line endings in a local working copy. A repository rule in .gitattributes gives everyone a shared convention and is usually clearer than asking each contributor to change a global Git setting.

Keep line-ending changes separate from code changes

If the project needs a one-time cleanup, make the normalization its own commit and explain that in the review. Follow it with a separate commit for the code edits. Reviewers can then inspect the cleanup and the actual changes independently.

A comparison tool can show where text differs, but it cannot decide which line-ending convention a project should use. Confirm the repository policy before changing files, and keep the final review focused on the edits you intended to make.