Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NuGet updates convert csproj files from CRLF to LF #8642

Open
1 task done
adamralph opened this issue Dec 17, 2023 · 9 comments
Open
1 task done

NuGet updates convert csproj files from CRLF to LF #8642

adamralph opened this issue Dec 17, 2023 · 9 comments
Labels
L: dotnet:nuget NuGet packages via nuget or dotnet T: bug 🐞 Something isn't working

Comments

@adamralph
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Package ecosystem

NuGet

Package manager version

No response

Language version

No response

Manifest location and content before the Dependabot update

https://github.com/adamralph/minver/blob/main/MinVer.Lib/MinVer.Lib.csproj

dependabot.yml content

https://github.com/adamralph/minver/blob/main/.github/dependabot.yml

Updated dependency

NuGet.Versioning from 6.7.0 to 6.8.0

What you expected to see, versus what you actually saw

Expected: Only the dependency updated, with line endings left the same.

Actual: The dependency updated, but all line endings change from CRLF to LF.

Native package manager behavior

Only the dependency update, with line endings left the same.

Images of the diff or a link to the PR, issue, or logs

https://github.com/adamralph/minver/pull/936/files

Smallest manifest that reproduces the issue

No response

@adamralph adamralph added the T: bug 🐞 Something isn't working label Dec 17, 2023
@jakecoffman jakecoffman added the L: dotnet:nuget NuGet packages via nuget or dotnet label Jan 2, 2024
@adamralph
Copy link
Author

More examples:

@fuzzzerd
Copy link

fuzzzerd commented Jan 8, 2024

I have had this happen in as well, unfortunately they're private repositories so I can't share a link to the pull, but the behavior is the same as the linked pulls here. Here is a screenshot, showing the that more than the version number has been changed:

line endings changed too :(

@fuzzzerd
Copy link

This issue just cropped up again on another project of mine as well:

diff with line endings changed

@aaron-kruse
Copy link

aaron-kruse commented Feb 6, 2024

Same issue here also in a private repo, I believe it started a few months ago. It might kind of go without saying, but this is on a Windows machine.

If it helps, I also found this in the update logs:

updater | Update complete.
updater | Fixing mismatched Unix line endings for [Web/Web.csproj].

With main checked out:

git ls-files --eol Web.csproj
i/crlf  w/crlf  attr/text=auto          Web.csproj

With a Dependabot branch checked out where line endings have been replaced:

git ls-files --eol Web.csproj
i/lf    w/crlf  attr/text=auto          Web.csproj

Content of .gitattributes file:

*		text=auto

# Scripts - override since bash throws errors if crlf is used
*.sh	text eol=lf

Note that with either of the two branches above checked out, when I open the file in Notepad++, the line endings are always crlf (I remember reading that the Git client does some "magic" using .gitattributes among other things to auto-convert line endings during checkouts/commits).

Additionally:

  • I have grouped pull requests enabled (not sure if that's related or not, but the timing might seem a little suspicious).
  • I've noticed on at least two occasions, the pull request will list a few packages as updated, but looking at the diffs, not all of those packages were actually updated. Again, I'm not sure if this is related or not, but both issues happened in the same pull request (line endings are converted and some packages referenced as updated weren't actually updated, but do have updates available).
  • This appears to be specific to *.csproj files (crlf is not getting replaced in a package.json file I have in this same repo).

@aaron-kruse
Copy link

aaron-kruse commented Feb 6, 2024

I checked the repo for the message I'm seeing in logs and found it seems to be coming from here:

puts "Fixing mismatched Unix line endings for [#{dependency_file.name}]."

Checking the blame and ignoring a commit to fix a typo, this seems to have been introduced on 11/27/2023 in Normalize updated content after running NuGetUpdater fdde9bd.

I did some poking around in our repo and found a PR opened by Dependabot on 11/25/2023 where the diff looked fine then another on 12/2/2023 where all the line endings were changed, which corresponds with the date of the commit above. Note that it's possible that the commit above isn't actually the cause of the problem, it might have just made an existing issue much more apparent (the commit above checks for mixed line endings and "fixes" them if necessary, but it's possible the line endings have been mixed for a long time and just weren't triggering something to change all line endings as a result).

Edit: this looks like it might be closer to the root of the problem:

@adamralph
Copy link
Author

Any update on this? It's still happening and it means I can't merge any dependabot PRs without considerable manual intervention.

@MitchellPaff
Copy link

+1

@maximilien-noal
Copy link

Same issue on this repo since a few days ago: https://github.com/OpenRakis/Spice86

See this PR: OpenRakis/Spice86#779

@kamronbatman
Copy link

kamronbatman commented Jul 13, 2024

It's completely unusable:
modernuo/ModernUO#1866

The \r\n vs \n detection is broken.

Note: I have a .gitattributes that enforces crlf on .csproj files, so it breaks my git locally when I pull that branch to "fix" it.
To recover, I have to delete .gitattributes, then reset the deletion, then checkout that file again, then switch branches before doing any other command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
L: dotnet:nuget NuGet packages via nuget or dotnet T: bug 🐞 Something isn't working
Projects
Status: Planned
Development

No branches or pull requests

7 participants