units: Restore original EOLs

[b4n]

Do not manage EOL for any test input that have non-LF EOLs, in order to keep the tests as they were originally meant to be.

Since 1efb9b9 all EOLs are converted by default, which is a problem for test files requiring a specific EOL type to work. Those should not see any conversion whatsoever, basically treated as binary data.

The changes here are mostly generated with:

$ find Units/ -name 'input*' -exec file '{}' ';' | \
  grep CR | \
  sed 's/: .*$//' | \
  while read -r f; do \
    d="${f%/*}"; \
    b="${f##*/}"; \
    echo "$b -text" > "$d/.gitattributes"; \
    git add "$d/.gitattributes"; \
  done

---

@masatake I see there was an attempt at this before #3425, what was the exact issues it created?
Couldn't we to something like this? (remove the text attribute rather trying to remove the auto value)

/Units/**/input* -text

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.95%. Comparing base (74ff528) to head (3148a3b).
Report is 11 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4268   +/-   ##
=======================================
  Coverage   85.95%   85.95%           
=======================================
  Files         246      246           
  Lines       63470    63434   -36     
=======================================
- Hits        54554    54525   -29     
+ Misses       8916     8909    -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[masatake]

When I proposed #3425 after getting the pull request #3424.
Though the original commit of #3424 was lost by force-pushing. However, as far as I can remember, the original #3424 included many EOF conversions.
I assumed the original author of the pull request included the conversions unintentionally. I thought unintentional conversions came from d89c9f2 .

To merge #3424, I merged #3425 quickly.
I should have taken more time to decide what to do with the conversions.

/Units/**/input* -text

This is one way. I don't object to this change. If I get a pull request similar to the original commit of #3424, I can now advise the author of the new pull request what to do.

However, I like this pull request more than the "just-one-line" solution.
This change, adding gitignore files, helps the reader of the test cases know "these input* files are special."
Therefore, I would like to merge this pull request.
In addition, I want to add the following change to our document:

diff --git a/docs/testing-parser.rst b/docs/testing-parser.rst
index 72edf8688..8e7f4595f 100644
--- a/docs/testing-parser.rst
+++ b/docs/testing-parser.rst
@@ -136,6 +136,19 @@ have its own directory under Units directory.
 	language parsers enabled/available can be checked with passing
 	``--list-languages`` to ctags.
 
+*Units/TEST/.gitattributes **optional**
+
+	This file specifies how to handle input files that require special care
+	when they are saved to or checked out from a Git repository.
+	The typical case is that you want git not to do any EOL conversion. In such
+	case write to the file like:
+	::
+
+	   input.xml -text
+
+	See also
+	`units: Restore original EOLs <https://github.com/universal-ctags/ctags/pull/4268>`_.
+
 Note for importing a test case from Test directory
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[b4n]

OK. The only thing is that if text is set on any test file, they could also be checked out as CRLF, depending on external factors like user platform or configuration. It could.be problematic with any test case where eol type matters -- and could for example lead a Windows developer not to ever test with LF alone.

Basically the issue I see is that test case inputs might not be consistent across checkouts, which might lead to confusion or let weird bugs go unnoticed.

OTOH if the line ending shouldn't matter for the issue, maybe it's a potentially good thing (although a bit unreliable) that it can get checked out with a wider range of EOLs to create virtual additional variations tested. But maybe if we really want this we should add the specific versions we want to test, which would not depend on luck.

[masatake]

Sorry to be late. This issue is so complex that I feel like running away.

OK. The only thing is that if text is set on any test file, they could also be checked out as CRLF, depending on external factors like user platform or configuration. It could.be problematic with any test case where eol type matters -- and could for example lead a Windows developer not to ever test with LF alone.

It is very problematic.
Specifying eol=crlf explicitly looks better:

-text eol=crlf

What do you think?

[b4n]

Hum, but do we want to specify everything manually? If we can let Git not change anything in all test input, wouldn't that be better?
Also not sure if eol has any effect if text isn't set, is it?