Propagate .gitattributes to Nextstrain pathogen repos

[joverlee521]

We had a question Nextstrain office hours where a user was running into an error with the curate rule in the ingest workflow:

/usr/bin/env: ‘python3\r’: No such file or directory

@genehack flagged that this is likely an issue with line endings in Slack, which reminded me that we added .gitattributes in #37 for this exact reason!

We should propagate the .gitattributes file to all the Nextstrain pathogen repos so that Window's users are less likely to run into this error.

TODOs

Pathogen repos from https://github.com/search?q=topic%3Apathogen+topic%3Anextstrain&type=repositories

• avian-flu Add .gitattributes file avian-flu#76
• dengue Add .gitattributes file dengue#81
• Add .gitattributes file ebola#9
• forecasts-ncov Add .gitattributes file forecasts-ncov#105
• Add .gitattributes file hbv#16
• Line endings are CRLF measles#29 Add .gitattributes file measles#51
• Add .gitattributes mers#1
• Sync .gitattributes with pathogen-repo-guide mpox#260
• Add .gitattributes mumps#9
• ncov Add .gitattributes file ncov#1125
• ncov-ingest Update .gitattributes with EOL settings ncov-ingest#464
• rsv Add .gitattributes file rsv#71
• seasonal-flu -> already exists
• Add .gitattributes tb#12
• zika Add .gitattributes file zika#71
• zika-tutorial Add .gitattributes file zika-tutorial#15

Other pathogen repos:

• nextstrain/seasonal-cov@ec466b5
• nextstrain/yellow-fever@8b67f61
• nextstrain/rabies@ad0b045

Following .gitattribute docs to normalize line endings of existing files in repos.

[genehack]

Done for seasonal-cov and yellow-fever — note that seasonal-cov had .gitattributes in .gitignore so that needed to be adjusted as well; not sure where that came from originally (and didn't try to track it down either...)

[joverlee521]

@genehack raised a question in the Nextstrain dev chat of whether forcing LF line endings could cause unexpected behavior for Windows users outside of Docker. @victorlin is exploring behaviors with .gitattributes on a Windows laptop.

[victorlin]

I just tried some different scenarios detailed below. Let me know if you can think of other scenarios to test.

TLDR: text files are handled properly with * text=auto eol=lf or * text eol=lf. We settled on * text=auto eol=lf in #37 (comment)

What does a Windows text editor do?

I tested two common editors: Notepad (Windows version 21H1) and VS Code (1.90.2).

• Both editors detected CRLF or LF on existing files and kept consistent when making changes.
• Both editors saved new files as CRLF. This is where having the right .gitattributes is helpful.

What does .gitattributes do?

From git docs:

These attributes affect how the contents stored in the repository are copied to the working tree files when commands such as git switch, git checkout and git merge run. They also affect how Git stores the contents you prepare in the working tree in the repository upon git add and git commit.

This seems to be accurate. Steps done to verify (all commands run on Windows PowerShell):

• Cloning zika (no .gitattributes) resulted in CRLF on all text files - no good.
• Cloning mpox (which currently has * text eol=lf) resulted in LF on all text files. Good!
• Cloning mpox from an old branch without .gitattributes resulted in CRLF on all text files. Switching branches to latest master resulted in LF on all text files. Good!
• Cloning pathogen-repo-guide (which currently has * text=auto eol=lf) resulted in LF on all text files. Good!
• New text files with * text eol=lf or * text=auto eol=lf get stored in git as LF upon git add. They're kept as CRLF locally but a git switch to a commit without the file then back to a commit that adds the file results in conversion to LF. Good!

[genehack]

....and done! 🙌

[joverlee521]

Thanks for pushing this through to the end @genehack 🌟