Do we really need a .gitattributes file for special handling of line endings?

We’ve had this .gitattributes file since day one – probably because this project grew out of boilerplate from previous mySociety django projects that involved Windows developers.

But the line ending stuff leads to odd surprises when you check in a new type of file. For example, here was me checking in a few jpg files earlier:

~/Work/mySociety/caps ⌘ git commit -am 'Fix broken team avatar images on interstitial modal'
warning: CRLF will be replaced by LF in caps/static/img/avatar-grace.jpg.
The file will have its original line endings in your working directory
warning: CRLF will be replaced by LF in caps/static/img/avatar-isaac.jpg.
The file will have its original line endings in your working directory
warning: CRLF will be replaced by LF in caps/static/img/avatar-zarino.jpg.
The file will have its original line endings in your working directory
[master 886d8c7] Fix broken team avatar images on interstitial modal
 2 files changed, 0 insertions(+), 0 deletions(-)
 rewrite caps/static/img/avatar-grace.jpg (95%)
 rewrite caps/static/img/avatar-isaac.jpg (82%)

It’s been suggested that maybe * text eol=lf isn’t the best way to achieve what we’re after. Or maybe we don’t need the file at all any more.

@ajparsons (as our resident Windows developer!) and @struan to discuss.

Read the repository’s .gitattributes file and review the reported warnings for caps/static/img/avatar-grace.jpg, caps/static/img/avatar-isaac.jpg, and caps/static/img/avatar-zarino.jpg. Reproduce the line-ending behavior with Git, then determine whether the current rules should be removed or revised and verify that new file types no longer produce unexpected handling.