--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8e1dfaeb-ff49-4510-871e-4743d0ea9e9an%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8e1dfaeb-ff49-4510-871e-4743d0ea9e9an%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/10c0f3f6-7fb7-4eb0-86dd-6e6dd0b7efb9n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1ee86163-7e64-4451-82f8-e182a4d1e938n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1ee86163-7e64-4451-82f8-e182a4d1e938n%40googlegroups.com.
Jason,
I'm no expert in these matters but I think the mentioned
.gitattributes will not enforce encoding they
will simply suppress any conversion. So if a user editor
or tool does mess up line-endings, it won't correct them
and also won't warn us.
Maybe there are other ways to enforce line-endings on checkin,
but all advice I found on Stackoverflow etc. points to enabling
the CRLF->LF conversion on input. You can still
tell it to leave LF->LF untouched on output so Windows
users can still (and should still) try to work with LF files, but
with a safety net. ;-)
https://stackoverflow.com/a/42135910/13250135
Note, that some bugs in git have been fixed and I suspect the
CRLF line that came from me might be due to a git version older
than the mentioned 2.10 installed on my old Windows PC back then.
https://github.com/git/git/blob/master/Documentation/RelNotes/2.10.0.txt#L248
Tony, what version of git have you installed?
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/a2289a9e-0393-4c75-ae61-7552b0b086b2n%40googlegroups.com.
Jason,
I'm no expert in these matters but I think the mentioned .gitattributes will not enforce encoding they will simply suppress any conversion. So if a user editor or tool does mess up line-endings, it won't correct them and also won't warn us.
How do you ensure new files don't get introduced with CRLFs? Looking at them on the GitHub web doesn't provide any indication of what line endings are used. Are you going to have an automated way of checking files?
> Tony, what version of git have you installed?
git version 2.21.0.windows.1I also use the free version of SmartGit as a graphical interface. I suppose that could be introducing some problems but I don't explicitly know of any CRLFs that I have introduced since I set core.autocrlf=true. Unfortunately, I don't know exactly when I made that change (due to a mistake that prevented my git configuration files from being backed-up) so I don't know for sure.Aren't there files that should have CRLF endings - like Windows .bat files? Maybe modern Windows can handle LF line endings too?
Jason,How do you ensure new files don't get introduced with CRLFs? Looking at them on the GitHub web doesn't provide any indication of what line endings are used. Are you going to have an automated way of checking files?
> I'm pretty sure that the reason this comes up is that when a PR is submitted we see a bunch of lines that look changed, but have not been, because the line endings have been changed. So I think we can catch it there.That's only true for existing files, I'm specifically talking about new files.
TonyOn Tuesday, February 9, 2021 at 12:21:30 PM UTC-6 Jason von Nieda wrote:> Tony, what version of git have you installed?
git version 2.21.0.windows.1I also use the free version of SmartGit as a graphical interface. I suppose that could be introducing some problems but I don't explicitly know of any CRLFs that I have introduced since I set core.autocrlf=true. Unfortunately, I don't know exactly when I made that change (due to a mistake that prevented my git configuration files from being backed-up) so I don't know for sure.Aren't there files that should have CRLF endings - like Windows .bat files? Maybe modern Windows can handle LF line endings too?That would be the only one I can think of, and we've got only one of them, and it hasn't been changed in 10 years. I'm not going to sweat it. I think LF will actually work fine, as well.Jason,How do you ensure new files don't get introduced with CRLFs? Looking at them on the GitHub web doesn't provide any indication of what line endings are used. Are you going to have an automated way of checking files?I'm pretty sure that the reason this comes up is that when a PR is submitted we see a bunch of lines that look changed, but have not been, because the line endings have been changed. So I think we can catch it there. If it continues to be an issue I can add a rule to the CheckStyle plugin, which is run with the Maven tests, to ensure no CR in Java files.Jason
--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/920817a8-eac1-46d1-bb7f-bdd7c0311c20n%40googlegroups.com.
> I'll add the rule to CheckStyle. This will cause `mvn test` to fail if there are CRLF
Perfect!
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyrJw7WFnj7MpgiwvHNwL6YxiYZxNAuB%3D%2BUL3y_YoNAjQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/ba88ef4e-5b20-3f18-df5c-1dc7aa0f058a%40gmx.net.