為什么Git在Linux上將CRLF轉換為LF？

Question

我有一些需要有LF行結尾的shell腳本（我在Ubuntu 14.04上）。 由於這是一個跨平台的開源項目，因此.gitattributes文件用於使行結尾“自動”工作。 不幸的是，他們沒有。

$ cat .gitattributes
# automatically normalize line endings
* text=auto

我的文件系統上有以下文件：

$ file extract.sh 
extract.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators

如果我現在使用dos2unix處理它，它會正確顯示為LF終止。

$ file extract.sh 
extract.sh: Bourne-Again shell script, ASCII text executable

另外， git顯示為已修改：

$ git status
[..]
Changes not staged for commit:
[..]

    modified:   extract.sh

現在我將它添加到索引：

$ git add extract.sh 
warning: LF will be replaced by CRLF in extract.sh.
The file will have its original line endings in your working directory.

但是一個新的git status顯示了這一點：

$ git status .
[..]

nothing to commit, working directory clean

並且file顯示為未更改：

$ file extract.sh 
extract.sh: Bourne-Again shell script, ASCII text executable

但是，如果我將其刪除並再次檢出：

$ rm extract.sh 
$ git checkout extract.sh
$ file extract.sh 
extract.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators
$ git status .
[..]

nothing to commit, working directory clean

即使從緩存中刪除它也無濟於事：

$ git rm --cached extract.sh
$ git reset --hard
$ file extract.sh 
extract.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators

100美元的問題是：如何讓git給我一個LF終止文件？

Answer 1

來自http://git-scm.com/book/en/Customizing-Git-Git-Configuration

如果您使用的是使用LF行結尾的Linux或Mac系統，那么您 不希望Git在您簽出文件時自動轉換它們; 但是，如果意外引入了CRLF結尾的文件， 那么您可能希望Git修復它。 您可以告訴Git 在提交時 將CRLF轉換為 LF，但不能通過將core.autocrlf設置為 輸入 來反轉 ：

git config --global core.autocrlf input