Add a .gitattributes files

[ericcornelissen]

Issue: Related to #1427

Description

The Composer/Packagist issue convinced me to implement this (though it turned out to not be strictly necessary from an export-ignore point of view), but I have been thinking about adding a .gitattributes file to the project for a long time. The primary things it will provide us with is better diffing and more consistency across platforms (e.g. line-endings).

The contents of the file are obviously open for discussion 🙂

[birjj]

My only question is what impact the export-ignore lines have on our project. Does NPM or GitHub use the git archive-generated export?

Everything else looks good to me (and a welcome configuration change). Thanks for handling it! Also sorry for the super late review.

[ericcornelissen]

My only question is what impact the export-ignore lines have on our project. Does NPM or GitHub use the git archive-generated export?

On GitHub it affects the content so the zip file you get when you download the repository as zip (repository homepage > "Clone or download" > "Download ZIP").

As far as I know(/can tell) it doesn't affect NPM releases and running npm publish just looks at the files in the directory, ignoring only files specified in .npmignore (or .gitignore);

Also sorry for the super late review.

Not a problem 😉

[birjj]

I think that in that case I'd prefer not excluding files from it. When clicking the download button I would expect to get a ZIP of all the files I see in the web interface too.

[ericcornelissen]

I think that in that case I'd prefer not excluding files from it. When clicking the download button I would expect to get a ZIP of all the files I see in the web interface too.

I can agree with that to some extend. To clarify, the export-ignore is intended to be used to manage what is included in the archive when you run the git archive command. The fact that GitHub uses that to generate the zip file may lead to awkward situation when a user expects that the download the whole repository. However, I think that is primarily GitHub's issue, not ours.

Regardless, I do agree that if you use it for that purpose the number of files ignored in the export can be far less. For now I have reduced it to:

• CNAME: only relevant for our GitHub pages site.
• .github (folder): is only relevant to GitHub, not the project itself.
• .gitpod.yml: is only relevant on GitHub, not to the project itself.
• .travis.yml: is only relevant on GitHub, not to the project itself.