I know this seems a bit like a crazy idea but maybe we don't strip the\r out but instead format the changelog with\r\n or windows style, because then it is always readable cross-platform. If we remove the\r then we restrict it only to Linux machines for reviewing the changelog and it does not work inheritly on windows. However the reverse will work on both.

Maybe this actually just bleeds into the code that handles the rendering rather than the content of the commit message. So it is likely your modification to remove them essentially is correct, then the during the writing of the file is when we apply the\r\n's.

I don’t think that’s necessary? The rest of the codebaseand most of the generated changelog is already using regular UNIX style CRs and it doesn’t sound like that’s caused any issues for people?

Also, Ithink Python in normal cases will honoros.linesep when writing files, though in this case since we’re using Jinja, the behavior could be slightly different.

Either way, I think removing the mixed in ones should work for most. For sure IDEs and common text editors on Windows will render it fine, and I think other editors will as well, whereas with the\r\n you’ll see^Ms in the file (as you do now insome lines on this project’s changelog).

btw, I don’t think these were introduced via commits on windows machines. I think maybe it’s how the strings are coming back from PyGithub, but could be wrong.

I noticed that if someone uses the GitHub editor to make a commit that the commit message from the text area in the webUI will create commits with/r/n. That is more likely where those odd ones are coming from in our changelog.

I like the second way as stated above. Thanks for the effort

Updated.

I noticed that if someone uses the GitHub editor to make a commit that the commit message from the text area in the webUI will create commits with /r/n.

Nowthis makes a lot of sense, and that's probably the reason.