Fixing the line-endings in a Git repository using the `.gitattributes` file
Asked Answered
S

1

4

What needs fixing:

I have a repository containing a single .md file, which contains an essay I am writing.

I edit the file from a few different computers, one running Linux and a couple running Windows.

Looking at a git diff in Windows now where I have made some changes, I can see my essay showing as nicely separated lines of text ... all about to be removed and replaced by one long line where what were paragraphs are separated by ^Ms.

I'm aware that ^M refers to Windows' CLRF line endings.

The diff result implies that I started the file in Linux (entirely possible; I don't remember) and have since saved it in Windows and that all the line endings have been replaced.

I'd like to be able to open files across both OSs with lines displaying as they should, and have a diff result that shows line breaks (rather than ^M placeholders) and only changes to the actual content.

What I've tried:

I have done some background reading, read a nice overview of line-endings and Git settings, and even tried following the commands in another Stack Overflow question.

As it stands I have one .gitattributes file at the top-level of repository which I've committed to the repository itself. It contains just two lines:

# These files are text and should be normalised (convert Windows' CLRF to LF)
*.md text

I've tried this (source):

git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"

And this (source):

git rm --cached -r .
git config core.autocrlf input
git diff --cached --name-only -z | xargs -0 git add
git commit -m "Fixed crlf issue"

In the second case, the last command tells me there is nothing to commit. (I also don't like the idea of changing the core.autoclrf since I'm trying to do this purely through .gitattributes, but I'm getting frustrated.)

Happy to answer questions and provide more details. Any ideas where I could be going wrong? Am I missing a step?

Sodium answered 17/2, 2014 at 12:17 Comment(2)
As a side note, you could define aliases that add -Xignore-all-space to diff and merge so you'd be less bothered with white space changes (you may want to look for a strategy that only ignores line endings, rather than all space).Philtre
Thanks @Shahbaz, I'll try playing around with that a bit later and report back.Sodium
F
1

Try just using

*.md text eol=native

instead of

*.md text

in your .gitattributes.

I did set up a small test repo with a CR-LF file in it and followed your first procedure to perform normalization:

git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings"

That correctly normalized file on check-in. But, weirdly, it still maintained CR-LF when checking-out, even if I am on OSX.

Supposedly, default value for core.eol is native. So, I expected git to checkout my files using just LF. But it seems that for some reason, it's just not doing that. So, my understanding of .gitattributes is flawed, or we have a bug to be filed to git...

In any case, explicitly setting eol=native in .gitattributes did the trick for me, as I said.

Fouquet answered 17/2, 2014 at 15:55 Comment(1)
Hi @eleom, thanks for this answer. It has indeed worked for one of my computers and having looked into it a bit more I think I have some answers to the questions implied by your expectations around eol. I will check this from my other computers (later today, I hope) and if it works from them too, I'll mark this correct and add some more information. Thanks again.Sodium

© 2022 - 2024 — McMap. All rights reserved.