Open alexlehm opened 1 year ago
The current behavior of Gitea:
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 (https://github.com/go-gitea/gitea/issues/9108)
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
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.
(the same issue is present in other forks of the software including gogs)
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?
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
I see. Wasn't aware we copy the description field into the generated README.
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
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.
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
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?
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.
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.
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