2014-11-25 110 views
0

當我做git status我看到這一點:`git的status`和EOL檢測

Changes not staged for commit: 
    (use "git add <file>..." to update what will be committed) 
    (use "git checkout -- <file>..." to discard changes in working directory) 

     modified: project/schema-readme.md 
     modified: project/vp-automate.php 

奇怪的是,這兩個文件是實際修改 - 它們是二進制相同,逐字節。

現在我認爲我知道他們爲什麼打上了混帳的修改:這是因爲他們使用的CRLF行結束,而我們的項目最近增加了一個.gitattributes文件與此內容:

* text=auto eol=lf 

這應該意味着當承諾時,Git會實際更新它們以使LF行結束。那麼爲什麼git status將這些文件標記爲「已修改」,即使它們當前未被修改?

編輯:這是奇怪的,也有在我的項目更多的文件使用CRLF行結束和修改不檢測。我不明白什麼特別之處schema-readme.mdvp-automate.php了Git檢測它們進行修改。

回答

1

除SHA1校驗和外,Git還根據某些文件屬性檢測到更改的文件,這可能會導致這兩個文件被標記爲已更改。有關Git如何檢測文件更改的更多信息,請參閱answer to this question

0

請嘗試配置core.autoccrlf屬性。它主要用於Windows機器上,以確保本地文件使用CRLF作爲行結束符(因此它們可以在記事本等中使用),而存儲庫中的「內部」文件則保留「合適的」LF結尾。

從文檔(混帳配置--help):

core.autocrlf 
     Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in 
     your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed. 

另見https://help.github.com/articles/dealing-with-line-endings#platform-all - 如建議,在Linux上,你應該將其配置爲 「輸入」。

+0

事情是我不想CRLF - 由於各種原因,我們甚至需要在Windows上使用LF。這個問題完全是關於爲什麼Git檢測到一些未更改的文件已更改以及是否與行尾有關。 – Borek 2014-11-25 14:50:41