0

I have a utility which will run on both Windows and Linux. However, when I check the code into GitLab via Windows, it adds "cr" to the EOL character, making it "crlf".

I've tried adding ".gitattributes" to the root of a branch of the repository, with entries like:

*.sh binary

and

*.sh text eol=lf

However, when I check the branch out in a different location, the "crlf" is still there.

I've been using these URLs as references:

https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings

How do I make Git treat a file as binary?

Any ideas?

torek
  • 448,244
  • 59
  • 642
  • 775
Jack BeNimble
  • 35,733
  • 41
  • 130
  • 213

1 Answers1

1

The recommended approach for Git is to use the following:

*.sh text eol=lf

That means that the file is a text file, and it should always use LF characters, which is what you want for shell files. However, when you do that, you need to do git add --renormalize . and then commit both the changes and the .gitattributes file. Otherwise, if you've already checked the file in with CRLF endings, nothing will change.

If you really have files that are binary, such as small images, you can do this:

*.jpg binary

However, if you do that in this case, because the repository already contains CRLF endings, the file won't be modified, so you'll still end up with CRLF endings. For a true binary file, like an image, that's what you want, but for a shell script, that would be undesirable.

Note that if you have other files in your repository which are text, you can also do this:

*.c text

which will enable automatic line ending conversion, or if you just want all of the remaining file types to be automatically guessed, you can do this:

* text=auto

That will guess whether a file is text or binary based on whether it contains NUL bytes within the first couple kilobytes. Note that you still need to do git add --renormalize . and commit both the resulting changes and the .gitattributes for that to have any effect.

If you still see changes in the local working tree after running git add --renormalize . and committing, try using git grep -lP '\r' HEAD:FILE (replacing FILE) to see if the file has a CRLF at the end of it in the HEAD revision. If not, you've done it correctly.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • This looks great. I will try it! – Jack BeNimble Nov 13 '21 at 19:56
  • Question - if I do the "git add --renormalize .", will this add any new files in the directory to the commit? If I only want to commit specific files, I should get rid of the new files or specify that specific files in the "git --add" command? – Jack BeNimble Nov 13 '21 at 19:59
  • That will add new files in the directory to the commit. However, you need to invoke it on all files of the types you've specified, or you can end up with files that always show as modified in `git status`. You can specify those files specifically on the command line instead of `.` if you like, but be sure to specify all of the appropriate files. – bk2204 Nov 13 '21 at 20:12
  • I tried this, but I'm still having issues. git doesn't check in the line changes. The problem is I added the files beforehand. I've tried a bunch of things, but still no luck. How do force it to renormalize? – Jack BeNimble Nov 14 '21 at 13:23
  • If you're still having problems, I'd move the new files out of the way and run `git add --renormalize .`. Then you can use the text I just added in the last paragraph to verify that your committed contents are correct. – bk2204 Nov 14 '21 at 15:38
  • The only way I could get it to work was by modifying gitattributes, check in, then modify the script with a comment, then check in. At least it's working! For future reference, this is on Windows using Gitlab. Thanks for help. – Jack BeNimble Nov 14 '21 at 16:28