I tried committing files with CRLF-ending lines but it failed.
I spent a whole work day on my Windows computer trying different strategies, and was almost drawn to stop trying to use git and instead try mercurial.
Please share only one best practice per answer.
Don't convert line endings. It's not the VCS's job to interpret data -- just store and version it. Every modern text editor can read both kinds of line endings anyway.
Try setting the core.autocrlf configuration option to true. Also have a look at the core.safecrlf option.
Actually it sounds like core.safecrlf might already be set in your repository, because (emphasis mine):
If this is not the case for the current setting of core.autocrlf, git will reject the file.
If this is the case, then you might want to check that your text editor is configured to use line endings consistently. You will likely run into problems if a text file contains a mixture of LF and CRLF line endings.
Finally, I feel that the recommendation to simply "use what you're given" and use LF terminated lines on Windows will cause more problems than it solves. Git has the above options to try to handle line endings in a sensible way, so it makes sense to use them.
It should be either core.autocrlf=true if you like DOS ending or core.autocrlf=input if you prefer unix-newlines. In both cases, your Git repository will have only LF, which is the Right Thing. The only argument for core.autocrlf=false was that automatic heuristic may incorrectly detect some binary as text and then your tile will be corrupted. So, core.safecrlf option was introduced to warn a user if a irreversable change happens. In fact, there are two possibilities of irreversable changes -- mixed line-ending in text file, in this normalization is desirable, so this warning can be ignored, or (very unlikely) that Git incorrectly detected your binary file as text. Then you need to use attributes to tell Git that this file is binary.
Hat tip: http://kerneltrap.org/mailarchive/git/2008/4/16/1450834/thread