私は、 Core.autocrlf設定がどのように機能するかについて、Stack Overflow のさまざまな質問と回答、およびgitドキュメントを読みました。
これは私が読んだ内容から理解したものです:
Unix および Mac OSX (OSX より前は CR を使用) クライアントは LF 行末を使用します。Windows
クライアントは CRLF 行末を使用します。
クライアントで core.autocrlf が true に設定されている場合、git リポジトリは常に LF 行末形式でファイルを保存し、クライアント上のファイルの行末は、クライアント上の行末ファイルの形式に関係なく、LF 以外の行末を使用するクライアント (Windows など) のチェックアウト/コミット時に相互に変換されます (これは Tim Clem の定義と一致しません - 以下の更新を参照してください)。
以下は、行末変換の動作が不明な、疑問符付きの core.autocrlf の 'input' および 'false' 設定について、同じことを文書化しようとするマトリックスです。
私の質問は次のとおりです:
- 疑問符は何にすべきでしょうか?
- このマトリックスは「疑問符なし」に対して正しいでしょうか?
合意が形成されそうになったら、回答の疑問符を更新します。
core.autocrlf 値
真偽入力
----------------------------------------------------------
コミット | 変換 ? ?
新規 | LF へ (LF に変換しますか?) (変換しませんか?)
コミット | 変換? いいえ
既存 | LF (LF に変換?) 変換
チェックアウト | 変換しますか? いいえ
既存 | CRLF (変換なし?) 変換
私は、さまざまな設定の長所と短所についての意見を求めているわけではありません。3 つの設定のそれぞれで git がどのように動作するかを明確に示すデータを求めているだけです。
--
2012年4月17日更新：読んだ後ティム・クレムの記事コメントで JJD がリンクしたように、上の表の「不明」値の一部を変更し、「checkout existing | true を、クライアントに変換するのではなく CRLF に変換するように変更しました。以下は彼が与えた定義で、私がこれまで見たどの定義よりも明確です。
core.autocrlf = false
これはデフォルトですが、ほとんどの人はすぐにこれを変更することをお勧めします。false を使用すると、Git はファイルの行末を一切変更しません。LF、CRLF、CR、またはこれら 3 つのランダムな組み合わせでファイルをチェックインしても、Git は気にしません。これにより、差分が読みにくくなり、マージが難しくなる可能性があります。Unix/Linux の世界で作業しているほとんどの人は、CRLF の問題がなく、ファイルがオブジェクト データベースに書き込まれたり、作業ディレクトリに書き出されたりするたびに Git が余分な作業を行う必要がないため、この値を使用します。
core.autocrlf = true
これは、Git がすべてのテキスト ファイルを処理し、そのファイルをオブジェクト データベースに書き込むときに CRLF が LF に置き換えられ、作業ディレクトリに書き込むときにすべての LF が CRLF に戻されることを意味します。これは、作業ディレクトリに CRLF を保持しながらリポジトリを他のプラットフォームで使用できることを保証するため、Windows で推奨される設定です。
core.autocrlf = 入力
これは、Git がすべてのテキスト ファイルを処理し、そのファイルをオブジェクト データベースに書き込むときに CRLF が LF に置き換えられることを意味します。ただし、その逆は行われません。オブジェクト データベースからファイルを読み込んで作業ディレクトリに書き込むと、行末を示す LF が残ります。この設定は、通常、Unix/Linux/OS X で、CRLF がリポジトリに書き込まれないようにするために使用されます。Web ブラウザーからコードを貼り付けて、誤って CRLF がファイルに書き込まれた場合、Git はオブジェクト データベースに書き込むときに CRLF が LF に置き換えられるようにします。
Tim の記事は素晴らしいですが、唯一欠けていると思うのは、リポジトリが LF 形式であると想定していることです。これは、特に Windows のみのプロジェクトの場合は必ずしも当てはまりません。
ティムの記事を最も投票数が多かった記事と比較すると答えjmlane によるこれまでのところ、真の入力設定については完全に一致していますが、偽の設定については一致していません。
ベストアンサー1
core.autocrlf仕組みについての最も良い説明は、git属性マニュアルページ、text属性セクション。
現時点では、次のように動作するようですcore.autocrlf(少なくとも私が知る限りでは、v1.7.2 以降)。
core.autocrlf = true
- リポジトリからチェックアウトされた文字のみを含むテキストファイルは、作業ツリーで
LFに正規化されます。リポジトリに含まれるファイルは変更されません。CRLFCRLF LFリポジトリ内に文字のみが含まれるテキスト ファイルは、リポジトリにコミットされるときに から に正規化されます。リポジトリ内に含まれるファイルはCRLFそのままコミットされます。LFCRLF
core.autocrlf = input
- リポジトリからチェックアウトされたテキスト ファイルでは、作業ツリー内の元の EOL 文字が保持されます。
- 作業ツリー内の文字を含むテキスト ファイルは、リポジトリにコミットされるとき
CRLFに正規化されます。LF
core.autocrlf = false
core.eol作業ツリーのテキスト ファイル内の EOL 文字を指定します。core.eol = nativeCRLFデフォルトでは、作業ツリーの EOL は、git がWindows マシン上かLF*nix 上で実行されているかによって異なります。- リポジトリ
gitattributes設定は、リポジトリへのコミットの EOL 文字の正規化を決定します (デフォルトはLF文字の正規化です)。
私はつい最近この問題を調査しましたが、状況が非常に複雑であることがわかりました。このcore.eol設定により、EOL 文字が git によってどのように処理されるかが明確になりました。