Respect the end of line character of source files instead of clobbering it to the current platform's default #33
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hey @LilSpazJoekp , could you review and approve the workflow run? Thanks! |
8 tasks
CAM-Gerlach
force-pushed
the
respect-source-eols
branch
from
3e70574 to
4bcf798
Compare
|
@LilSpazJoekp Thanks! Looks like I missed a couple lines of test coverage; I tweaked the block to use getattr instead, which is both shorter/simpler and avoids the coverage issue. |
|
Thanks @LilSpazJoekp ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, docstrfmt arbitrarily converts the EoLs of any modified files to the default of whatever platform it happens to be running on, rather than properly respecting the EoL of the original file. Accordingly, this means users on Windows or other non-standard platforms that don't have their git settings set up to prevent this will clobber any file that docstrfmt modifies that they then check into the repo, converting it to non-standard CRLF (that will switch back and forth depending on the last platform to modify it) and modifying every line of the file, leading to a high chance of merge conflicts.
Like the previous issue, I ran into this on my PRAW PR and its a basic but unfortunately not uncommon mistake made by newer/smaller formatting tools that I've fixed for a number of others, so I figured I'd fix it and add some tests for it.