Preserving Carriage Return / Line Feeds in GIT repository when cloning or pulling

Question

Noticed something strange.... I'm using libgit2sharp to clone a repository. The clone command is pretty straightforward

LibGit2Sharp.Repository.Clone(sCorrectRepo, sExePath, oOpt)

The repository contains, amongst other things, a bunch of .sql files. On most machines these are perfectly fine, but on an occasional client machine I find that all \r\n - "carriage return line feed" line endings have been replaced by just line feeds \n

What could be happening here and, most importantly, is there something I can do to prevent it? In most of the SQL it doesn't matter that much but we have a few SQL statements that contain actual text including CRLFs and when those are changed to just LFs the text we're trying to use is no longer correct.

Now I'm not very familiar with git so I don't know what I'm doing. My guess would be that I would need to look at gitattributes and adding a line such as

*.sql binary

but how do I do this in an existing repository? I tried adding a gitattributes file to the .git folder on my windows machine but when I then try to commit (using tortoisegit) it doesn't see any changes.

My remote git repository is on azure-devops

Answer 1

Ok so the solution to this problem consisted of two parts. Firstly, as colinD already suggested in his comment I had to go and change the configuration. Which I did. But it still didn't work for me. The reason was that the last time I committed and pushed my .sql files it had already replaced all line endings with LF in the remote repository. So I removed all the SQL files, commmitted and pushed the removal, re-added them, committed and pushed the re-added sql files, and then it worked.

As suggested by @EdwardThomson in his comment I then reverted back to the default settings and I added a .gitignore file instead. In the .gitignore file - at the same level as the .git folder in Windows - I added

*.sql binary

Did the same exercise again, removing, commit/push then re-adding, commit/push and confirmed that this also works. As suggested this may be a more up to date and appropriate way to handle these.