I don’t want to unnecessarily open a ticket on Gitlab, so I’ll ask about it here first. I tried to do my first library merge request, and I checked my parts with KLC check scripts before submitting them. They passed with no errors even though they actually violate rule G1.7 about Unix line endings. That happened because I work on Windows, so Symbol Editor saved the files with Windows line endings. I looked at source code for rule G1.7 checker and the line endings are checked only when the script is run on Linux. There is somewhat cryptic comment “Windows automatically checks out with CR+LF line endings”. Any idea what that means? Why is the check performed only on Linux?
Not cryptic. It’s the well known setting of core.autocrlf in Git.
I see, but that doesn’t answer my question. I mean, the KLC check scripts are pretty thorough, so I don’t understand why is the G1.7 check performed only on Linux…
Windows users are expected to configure their Git client to convert the line endings? Or it should automatically read that setting from KiCad library repo?
Because git on Windows will by default check out to crlf. Git clients can be overrided to checkout LF on Windows on a project/global/system basis but it is annoying and non-default.
git config core.eol lf inside the checked out repo folder will configure it for that repo. However, refreshing the files that are already checked out is a PITA.
The guys that wrote the KLC scripts use linux more than anything so they didn’t want to bother with the overhead of making it work right/mandating people use core.eol set to lf on windows.
They should have made it a warning rather than failure on Windows in its current state.
You should be fine if you open a merge request as git stores the files with LF anyway and then the linux CI job will extract the files with LF and run against them.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.