Information Technology Reference
In-Depth Information
Even though the files in your working directory were not touched the above change
will confuse git. The command $ git status -sb will inform you that git con-
siders all the text files changed.
You can verify the changes in the working directory using the following command:
$ git diff --check
It will print the warnings about the changed line endings.
Hint If you are using Linux, you can skip the two commands: $ rm .git/in-
dex and $ git reset in this recipe; you will get the same results.
How It Works
The project reveal.js uses LF line endings. All text files stored in object database
use the line ending LF . When you perform a clone with autocrlf set to true , git
will—during a checkout—perform LF=>CRLF conversion; your working directory
will contain files with CRLF . The staging area, however, will use the original line end-
ings, that is, LF .
As long as you have autocrlf turned on, git will use the CRLF=>LF conversion
when comparing the working directory to the staging area. Therefore the repository re-
mains clean.
If you use $ git config --global core.autocrlf false to turn off
the conversion performed during check-in, git compares the working directory to the
staging area without any conversions. Because the files stored in these two locations
use different line endings, the $ git status command reports that there are un-
staged changes in your working directory.
This is a situation you should always avoid.
Imagine that right now in this state you want to contribute to reveal.js . You
change a single line in one of the files and then commit the change with the $ git
add -A and $ git commit commands. This revision, when accepted, would cause
a headache for the project leader and other developers as it introduces hundreds of
changes. All but one are not only unnecessary but would be probably reverted by the
next contributor who uses different line endings.
This recipe presents a pattern that you should always avoid.
Search WWH ::




Custom Search