EOL

[greenTara]

Recently it was discovered that the PHP script of the MYNG engine that generates the Relax NG driver schema produces a file that has a mixture of EOL notations. The file itself uses LF only, but PHP echo functions applied to a quoted string containing LF produces output with CR+LF.

Obviously, a mixture of EOL notations in one file is a bad thing. It is not difficult to rewrite the PHP scipt to produce one EOL notation or another. But this raises the question of - what should the EOL notation be?

Also there is the question of maintenance. Whenever there are multiple contributors, or even a single contributor using a variety of tools or platforms, there is a possibility that a commit is unintentionally made using an inappropriate EOL notation.

There is a git-based functionality to manage this problem: https://help.github.com/articles/dealing-with-line-endings/

1. Should we have .gitattributes files in our repositories?
2. If so, what is the convention for selecting the appropriate EOL handling?
3. Should .gitattributes be handled at the Organization level?

[gvdgdo]

1) It would appropriate to have .gitattributes files in the repositories to ensure consistent line endings. 2) In general Unix line ending (LF) is the most commonly used for shared projects. 3) I think they should handled at the Organisation level.

[greenTara]

On a related note,

I have created a test fix of MYNG to take care of the line-ending issue produced by the PHP. It is now available at http://deliberation.ruleml.org/1.01/relaxng/schema_rnc_test.php

For example, the URL http://deliberation.ruleml.org/1.01/relaxng/schema_rnc_test.php?backbone=x7&default=x7&termseq=x7&lng=x1&propo=x3cf&implies=x7f&terms=xf3f&quant=x7&expr=x0&serial=xf

will generate the driver schema with only LF end-of-line markers.

This fix will "go live" after Nov. 14, 2014.

[greenTara]

finished with https://github.com/RuleML/deliberation-ruleml/commit/4c4f3f31b28d9010f5098328863ffe0661cb876d

[greenTara]

It was necessary to revert this commit because it played havoc with the multiple branches that are waiting to be merged into some release. Once these branches are merged, then this fix can be re-applied. The procedure will be:

1. set core.autocrlf locally (in the case of Mac git config --global core.autocrlf input)
2. add the .gitattributes file (see https://github.com/RuleML/deliberation-ruleml/commit/4c4f3f31b28d9010f5098328863ffe0661cb876d)
3. follow http://git-scm.com/docs/gitattributes to commit the normalization of line endings to LF all at once