Issue with "Apply Change" when using autocrlf=false causing corrupt EOL

[Paul Langille]

So, we are using repo that use autocrlf=false for historical reasons - and the feature "Apply change" from a commit change commit only EVER uses LF (\n) to apply a multi-line change - ignoring the actual EOL used in the file.

The ideal is that Gerrit looks at the repo setting (local repo) for the autocrlf - and if false - would detect the files' EOL - and replace any \n with the EOL for the file - that might also require looking at the .gitattributes when no EOL exists in the file yet for the worst case.

This has resulted in files that are only CR or CRLF getting one or more LF in them - that causes EOL corruption (build breaks!) with EOL sensitive tooling.

Has this issue been ever posted about?

If there is some setting or change that could be done for this - this would be highly appreciated - note that - if this is already fixed in a newer version than 3.10.4 - I did not see it in any change logs (I am holding off a Gerrit server update on my server until I can get this fixed somehow - including building my own Gerrit build - but the plugin builds have been holding me back on that one - trying to get thirdparty ones working.)

[Matthias Sohn]

On Thu, Apr 30, 2026 at 3:52 PM 'Paul Langille' via Repo and Gerrit Discussion <repo-d...@googlegroups.com> wrote:

So, we are using repo that use autocrlf=false for historical reasons - and the feature "Apply change" from a commit change commit only EVER uses LF (\n) to apply a multi-line change - ignoring the actual EOL used in the file.

Where is this "Apply change" feature and how do you use it ?

core.autocrlf is a git option which only works in a clone having a working tree.

If set to true it converts the line endings in all files to CRLF on checkout.

The Gerrit server doesn't know which git options you set on your machine.

 

The ideal is that Gerrit looks at the repo setting (local repo) for the autocrlf - and if false - would detect the files' EOL - and replace any \n with the EOL for the file - that might also require looking at the .gitattributes when no EOL exists in the file yet for the worst case.

This has resulted in files that are only CR or CRLF getting one or more LF in them - that causes EOL corruption (build breaks!) with EOL sensitive tooling.

Has this issue been ever posted about?

If there is some setting or change that could be done for this - this would be highly appreciated - note that - if this is already fixed in a newer version than 3.10.4 - I did not see it in any change logs (I am holding off a Gerrit server update on my server until I can get this fixed somehow - including building my own Gerrit build - but the plugin builds have been holding me back on that one - trying to get thirdparty ones working.)

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/fbfbad61-cb40-47a8-8d0b-043d39504e1fn%40googlegroups.com.

[Paul Langille]

So, in regards to this issue - the  'Apply Change' I am referring to is the feature in the code review comments - where someone suggests a change - and the "Apply Change" is there in the Web UI - but the file is modified incorrectly on the server adding the lines as only LF - rather than the actual End-of-line marking of the file.

The fact that the repo cannot be properly marked with autocrlf=false is the key problem here. A way to configure a repo as using that option - and have the suggestion apply with the correct (.gitattribute) setting for the EOL marker is the KEY ask here.