When creating the initial README.md from the project creation page, the text lines have CRLF line endings when the client is Windows, but Gitea is running in Linux

[alexlehm]

Description

When creating the project description README.md file, the resulting file in the git has CRLF line endings on the part the is copied from the project description, when checking out in Linux the file is still using CRLF endings since no autoconversion is used.

Gitea Version

1.20.4

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

when looking at the resulting file checked out on Linux, it looks like this:

Git Version

2.30.2

Operating System

ubuntu 22.04.2 LTS

How are you running Gitea?

GITEA_WORK_DIR=$PWD/data/ ./gitea web -c $PWD/etc/app.ini -p 3003

Database

sqlite

[lng2020]

The current behavior of Gitea:

1. If you edit a file through the Gitea web editor, the CRLF will auto-translate into LF
2. If you upload a file in Windows through the web button, the CRLF will be unchanged.
3. If you upload a file in Windows through git, it depends on the config core.autocrlf and .gitattributes, see(https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings?platform=windows)

Related discussion (#9108)

[alexlehm]

This only happens when typing the text in the description form field, this is copied into the README.md file along with the project name and the lines from the description end up with CRLF

e.g. here. https://tildegit.org/alexlehm/test-test2

I fixed that by doing recode -f on the previous projects I created, I wonder if it would be possible to filter the description to remove the CR chars before creating the file

In fact it might work to open the README file with the web editor once and save it again to remove the CRs from the text

[lng2020]

This only happens when typing the text in the description form field, this is copied into the README.md file along with the project name and the lines from the description end up with CRLF

e.g. here. https://tildegit.org/alexlehm/test-test2

I fixed that by doing recode -f on the previous projects I created, I wonder if it would be possible to filter the description to remove the CR chars before creating the file

In fact it might work to open the README file with the web editor once and save it again to remove the CRs from the text

Well I guess the code forgets to remove the "\r" before generating the README.md file automatically. Will try to figure out and fix this one later.

[alexlehm]

(the same issue is present in other forks of the software including gogs)

[silverwind]

How exactly is the README generated for the issue to show? It is through this option in repo creation?

Is the README being edited in the web editor after repo creation?

[alexlehm]

I use Firefox in Windows and type multiple lines in the description field and create the default README.me file

it is not related to the web editor

[silverwind]

I see. Wasn't aware we copy the description field into the generated README.

[alexlehm]

the odd thing is, this feature is specific to gitea (and forks), both github and gitlab have a single-line description line that is copied into the readme which likely avoids the lineend issue

[silverwind]

So I guess we could normalize to LF here which is the most common EOL format in git repos. We have no .editorconfig, .gitattributes or any other indication on which EOL preference the user has at this point, so we have to choose one format and LF seems the most likely correct one.

[alexlehm]

i thought that as well, any README file will be unix format, if the user uses Windows they will usually have autocrlf active in their git config for the client

[lng2020]

Currently, due to the PR(#27141), the Monaco editor can auto-detect the EOL. So it won't encounter an error message even if the EOL is CRLF. That's the exactly same behavior with Github. I think it's better than changing the content silently.
Is it okay to close it now?

[silverwind]

I would keep open. The textarea in repo creation sends CRLF (as all textareas do by default). I would normalize this to LF so that we don't end up with a mixed EOL file.

[lng2020]

I would normalize this to LF so that we don't end up with a mixed EOL file.

Indeed. The README.md above is a mixed EOL file but the Monaco editor just work well.