file upload doesn't respect .gitattributes to normalize CRLF line endings #8051

Open
opened 2025-11-02 07:52:22 -06:00 by GiteaMirror · 2 comments
Owner

Originally created by @plgruener on GitHub (Oct 30, 2021).

Gitea Version

1.16.0+dev-444-g40c8451b7

Git Version

No response

Operating System

No response

How are you running Gitea?

Tested via https://try.gitea.io/plgruener/testCRLF

Database

No response

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Description

In a Git repo with a .gitattributes file with contents * text=auto, all newly added/staged files have their line terminators automatically converted from CRLF -> LF.
However, when you upload and commit a file with CRLF line terminators via the Gitea webinterface, the line endings are not normalized.

You can see this when you clone the example repo: crlf.txt was given CRLF (with the unix2dos utility) and uploaded via "upload file".
(Be careful to not enable core.autocrlf in your local Git config; and set core.eol=lf, else Git will convert every file to CRLF line endings.)
Also when you edit the example file again with the web editor (which forces LF line endings), you'll see that it reports seemingly identical changes on every line, indicating a line ending conversion.

(When copy-pasting the text in the "new file" web-editor, this is not immediately an issue, because the web editor forces LF line endings. But ideally, the editor should also respect .gitattributes, see #9108.)

Expected behaviour: be able to force the line ending style on all files by respecting the .gitattributes, whether they are submitted by push, by web-editor or by uploading a file.
If there's a workaround to just force LF on upload, that would be fine, but keep in mind that some files on Windows, eg .bat scripts, may require CRLF.

Screenshots

No response

Originally created by @plgruener on GitHub (Oct 30, 2021). ### Gitea Version 1.16.0+dev-444-g40c8451b7 ### Git Version _No response_ ### Operating System _No response_ ### How are you running Gitea? Tested via [https://try.gitea.io/plgruener/testCRLF](https://try.gitea.io/plgruener/testCRLF) ### Database _No response_ ### Can you reproduce the bug on the Gitea demo site? Yes ### Log Gist _No response_ ### Description In a Git repo with a `.gitattributes` file with contents `* text=auto`, all newly added/staged files have their line terminators automatically converted from CRLF -> LF. However, when you upload and commit a file with CRLF line terminators via the Gitea webinterface, the line endings are _not_ normalized. You can see this when you clone the example repo: [crlf.txt](https://try.gitea.io/plgruener/testCRLF/src/branch/master/crlf.txt) was given CRLF (with the `unix2dos` utility) and uploaded via "upload file". (Be careful to not enable `core.autocrlf` in your local Git config; and set `core.eol=lf`, else Git will convert _every_ file to CRLF line endings.) Also when you edit the example file again with the web editor (which forces LF line endings), you'll see that it reports seemingly identical changes on every line, indicating a line ending conversion. (When copy-pasting the text in the "new file" web-editor, this is not immediately an issue, because the web editor forces LF line endings. But ideally, the editor should also respect .gitattributes, see #9108.) Expected behaviour: be able to force the line ending style on _all_ files by respecting the `.gitattributes`, whether they are submitted by push, by web-editor or by uploading a file. If there's a workaround to just force LF on upload, that would be fine, but keep in mind that some files on Windows, eg `.bat` scripts, may require CRLF. ### Screenshots _No response_
Author
Owner

@baltitenger commented on GitHub (Jan 15, 2022):

This issue also affects lfs: it will add the files to git when they should be added to lfs instead, according to .gitattributes.

@baltitenger commented on GitHub (Jan 15, 2022): This issue also affects `lfs`: it will add the files to git when they should be added to `lfs` instead, according to `.gitattributes.`
Author
Owner

@zeripath commented on GitHub (Jan 15, 2022):

This issue is not about lfs - if you're certain that you have lfs running have the gitatrributes committed on the branch you're uploading to and you're definitely sure this should be applying then reopen a new issue giving all of the correct details.

This should be working on 1.16:

a38ab71b20/services/repository/files/upload.go (L95-L111)

@zeripath commented on GitHub (Jan 15, 2022): This issue is not about lfs - if you're certain that you have lfs running have the gitatrributes committed on the branch you're uploading to and you're definitely sure this should be applying then reopen a new issue giving all of the correct details. This should be working on 1.16: https://github.com/go-gitea/gitea/blob/a38ab71b20754619880d763040e3a24ebe11e4a4/services/repository/files/upload.go#L95-L111
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#8051