Closed hmh closed 5 years ago
@hmh Thanks for bringing this up. We are taking a look at it now. Are you only seeing this happen with the releasenote and license files? Or the kernel patches? Or any of the microcode binary files?
@hmh I tried a couple of things and I am not seeing an issue. I checked through all the text files in the repo with a hex editor and all EOLs are CRLF (0D 0A). I checked my repo that I stage the releases in versus a clone of the repo done to a Windows10 system and against a clone on a Linux system. Original files and cloned files are all binary matches. Could you post an example of what you are seeing and any additional details I may be missing on how to catch the issue? I would like to fix this prior to the next release.
Hmm, I apologise. I was misled by "git diff" showing "^M" only on a few lines, because the releasenotes file here changed from eol=lf to eol=crlf (which itself is not a problem at all).
Therefore, there is no issue: it was all a problem sitting somewhere between my chair and my keyboard :(
@hmh No problem. Thanks for letting me know.
Annoying CRLF terminators keep showing up just on some lines of the text files, making them a mess (EOL is neither just LF, or just CRLF, but a mix).
The easiest way to deal with this is likely to tell git that it is a text file and force the EOL convention (whichever one is fine, as long as it holds true for every line of the text file).
This is described in gitattributes(5). A commit changing the files will likely be required to clean them up for the first time.