4

I'm going to answer my question with the fix what solved my problem.

Note for downvoters: I understand that the root cause is discussed in various other threads (that is how I solved my problem). This post is more about how having a dual boot system can lead you to this issue. So no, this question/answer is not a duplicate, but a particular instance of a general class of problems, adding more cases to SO's repository on this issue.

At home: I code in Linux. LF used as line ending
At the office: I code in windows. CRLF used as line endings.
By default, git's autocrlf feature (https://stackoverflow.com/a/20653073/2715083) keeps things happy.

However, if you run a dual boot system with Linux and Windows, you can mess yourself up in the following way:

  1. git pull some files you worked on in a linux environment in a windows environment, in a location that can be accessed from the dual-booted linux environment. This modifies the files to contain CRLF endings.
  2. Then when you open up the file in linux, where the default is only LF, git diff will say entire file is modified, because each LF got changed to CRLF at every single line. (I was warned by Atom, which has this diff count inbuilt)
Somjit
  • 2,503
  • 5
  • 33
  • 60
  • These issues have already been discussed [here](https://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf?noredirect=1&lq=1), [here](https://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operat) and in plenty of other threads. [here](https://stackoverflow.com/a/29888735/365237) is a clean way of working around if you want your files re-checked out. – eis Aug 09 '17 at 19:29
  • Possible duplicate of [git replacing LF with CRLF](https://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf) – eis Aug 09 '17 at 19:29
  • @eis be so kind as to see my edit :) – Somjit Aug 09 '17 at 19:40
  • I still think this is a duplicate, already answered [here](https://stackoverflow.com/questions/1967370/git-replacing-lf-with-crlf/29888735#29888735) and [here](https://stackoverflow.com/questions/9976986/force-lf-eol-in-git-repo-and-working-copy/42135910#42135910), for example. – eis Aug 10 '17 at 05:20
  • 1
    @eis okay cool. As long as it helps someone, being a duplicate doesn't matter. – Somjit Aug 10 '17 at 05:38

2 Answers2

2

you are talking about text=auto part? I wasn't sure If I need to include that in a new .gitattributes file or not, because when I did, ATOM still showed the files as modified.

Yes, it does.
To force Git to apply .gitattributes directives, see "Dealing with line endings".

I would first make sure core.autocrlf is set to false. 

git config --global core.autocrlf false

Then:

git add . -u
git commit -m "Saving files before refreshing line endings"

rm .git/index

git reset

git status

git add -u
git add .gitattributes

git commit -m "Normalize all the line endings"

You can also use, to force the index re-normalization:

git rm --cached -r .
git reset --hard

See "Force LF eol in git repo and working copy"

* text=auto eol=lf
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks for the detailed steps! By forcing all line endings to be `LF`, will it cause any problems in windows kinda places where `CRLF` is the norm? – Somjit Aug 09 '17 at 19:43
  • 1
    @Somjit It depends on the type of file and of your IDE. You can restrict the `* text=auto eol=lf` to `*.xxx` (a certain extension) – VonC Aug 09 '17 at 19:43
  • Yeah, I guess most code editors will be okay. Thanks for pointing out the custom extension mod. – Somjit Aug 09 '17 at 19:46
-1

The FIX

  1. Delete/move to another location the problem files/folders
  2. do git checkout <hash> <your/files/location>

where <hash> is for the last good commit, and your/files/location being the location of the files you want to cure from the CRLF problem. This will basically restore the older versions from your local .git repository.

Worked for me.


If you know something i missed, or explained incorrectly, do let me know

Somjit
  • 2,503
  • 5
  • 33
  • 60
  • You are circumventing the problem. To really fix it, use a '.gitattributes' file – Philippe Aug 09 '17 at 19:13
  • @Philippe you are talking about `text=auto` part? I wasn't sure If i need to include that in a new `.gitattributes` file or not, because when I did, ATOM still showed the files as modified... – Somjit Aug 09 '17 at 19:20