3

I've been experiencing a rather strange issue and I wanted to see if anyone else had experienced the same and if they had found a solution.

For a given web project, I download Font Awesome, include the CSS files and make sure that all files are being loaded correctly (no 404s) and everything works fine. I do some work on the project and then finish up with a git commit/push.

Trouble is, often when I then go to another machine and do a git clone/pull all of the font icons which worked great on the original machine show up as boxes! Still no 404 errors reported by the console. As soon as I re-download Font Awesome and re-copy the files (they are there, they just don't work) everything works fine again.

Has anyone had problems with git corrupting font files? Or is there something else in my workflow that's borked? Help and advice is much appreciated.

Update: Issue Resolved

The quick fix was to switch to a CDN to load the files. I was initially reluctant to do this because I was worried about load times but it was more than fine, plus it put less of a load on my server.

The actual issue was with the line endings of the file. If developing on Windows (and unfortunately I am) then git sometimes (often) checks out files with Windows-style line endings and commits them with Linux-style. For some reason this corrupted the Font Awesome font files.

So the more detailed fix (if you're adamant about not using a CDN) is to make sure that git keeps the original line endings of the Font Awesome files, and doesn't change them on commit/checkout.

Jamison Bryant
  • 420
  • 3
  • 12

2 Answers2

2

It might be caused by core.autocrlf feature of git.

Those binary files will get collapsed when the option is true.

koji matsumoto
  • 36
  • 1
  • Good advice. Maybe if Jamison answers, you point him to the docs on how to override autocrlf for these files. – Barett Apr 02 '15 at 18:15
0

Not sure why this is happening from your description, but many savvy developers with modern projects use a mixture of or number of cascading dependencies:

  1. By default, use a font-awesome CDN (see: http://www.bootstrapcdn.com/#fontawesome_tab) which will prevent these issues.
  2. If the above fails, fall back to local (on-domain) copy and version of the same.

Not a complete answer, but this will provide you with a CDN version of your library of choice -and- where you need it, a local version that you can depend upon.

There are a few JS libraries out there that allow you to fall-back on local copies of libraries, but this question covers a few techniques:

How to load local script files as fallback in cases where CDN are blocked/unavailable?

Community
  • 1
  • 1
nickhar
  • 18,621
  • 12
  • 56
  • 71
  • Thanks very much, @nickhar, I did end up falling back to a CDN. The issue was line endings being converted, as it always is. Thanks for the suggestion. – Jamison Bryant Apr 03 '15 at 23:26