Gitea should not convert newlines when editing a file through the web interface

[anthonyvdotbe]

Description

When editing a file through the web interface, Gitea converts CRLF newlines to LF.

The expected behavior would be for Gitea to apply the actual changes I make in the editor, use the original newlines from the file, and commit the file. Then Git (via properties such as core.autocrlf) would decide whether the newlines must be converted.

In other words, Gitea shouldn't be opinionated about newlines (even for new files, Gitea could offer a dropdown to choose the newlines to use).

Gitea Version

1.20.4

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

2.41 (git version 2.41.0.windows.1)

Operating System

Windows 11 (Microsoft Windows 10.0.22621)

How are you running Gitea?

Using the official gitea-1.20.4-windows-4.0-amd64.exe, running as a Windows service as described in the Gitea docs.

Database

SQLite

[silverwind]

What if the file is mixed LF and CRLF newlines? It would need a (potential expensive) heuristic.

[delvh]

I think @anthonyvdotbe has described it quite well:

In other words, Gitea shouldn't be opinionated about newlines

We should simply accept whatever the user tells us to use.

[silverwind]

A user option might be nice, but without an option, we can only guess the dominant ending. Browsers default to LF endings, by the way, even on Windows.

[silverwind]

Actually I think a user option is a bad idea. Preferred ending for a repo should be set in .gitattributes or .editorconfig and users are bound to honor these config files when editing, not introduce line ending inconsistency in otherwise consistent repos.

[delvh]

I repeat myself:

We should simply accept whatever the user tells us to use.

And nothing else. End of discussion.

[silverwind]

The problem is, users likely don't even know which format they want or in which format the repo they are editing is. GitHub also does not have an option for this. If an option is provided, it should default to a heuristics-based value on the edited file.

In any case, I see the discussion as pointless because LF is the only sane configuration.

[anthonyvdotbe]

It seems like the discussion is focused on new files now, but my main issue is with modification of existing files: if I've already committed a file with CRLF line endings, maybe I have explicitly configured Git and/or EditorConfig to use CRLF, or maybe I haven't configured anything and I don't care about line endings, or ... but no matter if I care or not: I don't want tools to silently convert newlines. For example, diff viewers like gitk will not give meaningful diffs because of this.

So when editing existing files, Gitea should just use the newlines as they already exist. In 99.9...% of the cases, a file will only have either LF or CRLF, not a mix of both. In the edge case of mixed newlines, Gitea can either refuse to allow editing (which makes sense to me: if I've managed to create a file with mixed newlines, I'd find it reasonable that I have to edit the file in a full-blown editor as well), or it can warn the user about the mixed newlines and force the user to choose one of them, or it can warn the user and just do a best-effort modification (e.g. if I fix a typo, it should still be doable to retain the mixed newlines correctly).

Sure, ideally Gitea would have support for all ways to specify newlines (Git/EditorConfig/...) and, when modifying a file with inconsistent newlines would warn about the inconsistency and propose the user to align with the specified newlines, but that would clearly be a feature, whereas the current behavior is, in my opinion, a bug.

[silverwind]

Should present a dropdown that defaults to a value derived from these in descending order:

• Editorconfig matching the current file path
• For existing files with at least 1 LF character in it, the file's dominant ending
• Gitattributes matching the current file path
• LF

No persistent user setting needed.

[silverwind]

For reference, monaco features this dominant line ending detection and APIs to override. Are we sure it's not already preserving the dominant line ending when editing existing files?

https://microsoft.github.io/monaco-editor/docs.html#interfaces/editor.ITextModel.html#getEOL
https://microsoft.github.io/monaco-editor/docs.html#interfaces/editor.ITextModel.html#setEOL
https://microsoft.github.io/monaco-editor/docs.html#interfaces/editor.ITextModel.html#pushEOL