Report removal of final newline #54
Merged
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
If a file does not end in a newline, then every line added to the end of the file results in a diff to the previous final line. An example using `\n` to symbolize end of line characters: https://github.com/arduino-libraries/Servo\n https://github.com/arduino-libraries/Stepper When another line is added at the end: https://github.com/arduino-libraries/Servo\n https://github.com/arduino-libraries/Stepper\n https://github.com/arduino-libraries/FooBar you can see there is necessarily a diff on line 2 even though the editor did not touch that line. For this reason, it is best practices to always retain a newline at the end of files. In addition to it being common practice, the GitHub web editor automatically adds this newline. Between this and my expectation that people would either add URLs to the top of the list or in alphabetical order, leaving the distant end of the file alone, I was hoping that this would not be a common problem with the library submission system, but this is simply not a realistic expectation. What I hadn’t considered is that the person to suffer for this formatting is the next to add a URL to the end of the file. Because of this “ghost diff”, the submission system sees this PR as a modification to an existing item on the list rather than an addition. I think this will be best handled by detecting and dealing with the problem at its introduction, rather than attempting to make the system resilient to a missing final newline.
per1234
added
type: enhancement
silvanocerza
approved these changes
Jul 26, 2021
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.
If a file does not end in a newline, then every line added to the end of the file results in a diff to the previous final
line.
An example using
\nto symbolize end of line characters:When another line is added at the end:
you can see there is necessarily a diff on line 2 even though the editor did not touch that line.
For this reason, it is best practices to always retain a newline at the end of files.
In addition to it being common practice, the GitHub web editor automatically adds this newline. Between this and my
expectation that people would either add URLs to the top of the list or in alphabetical order, leaving the distant end of
the file alone, I was hoping that this would not be a common problem with the library submission system, but this is
simply not a realistic expectation.
What I hadn’t considered is that the person to suffer for this formatting is the next to add a URL to the end of the
file. Because of this “ghost diff”, the submission system sees this PR as a modification to an existing item on the list
rather than an addition.
I think this will be best handled by detecting and dealing with the problem at its introduction, rather than attempting
to make the system resilient to a missing final newline.
The associated changes to the arduino/library-registry repository's "Manage PRs" workflow: per1234/library-registry@f8385ae
Demonstration of the updated parser in action: per1234/library-registry#8 (comment)