7
異なるオペレーティングシステム間でのgit core.autocrlfによる行末変換の動作
Stack Overflowに関するさまざまな質問と回答、およびcore.autocrlf設定がどのように機能するかに関するgitのドキュメントを読みました。 これは私が読んだことからの私の理解です: UnixおよびMac OSX(OSX以前のバージョンではCRを使用)クライアントはLF行末を使用します。 WindowsクライアントはCRLF行末を使用します。 クライアントでcore.autocrlfがtrueに設定されている場合、gitリポジトリは常にLFの行末形式でファイルを保存し、クライアント上のファイルの行末はチェックアウト/コミット時に前後に変換されます。 -LFの行末。クライアントの行末ファイルの形式に関係なく(これはTim Clemの定義と一致しません。以下の更新を参照してください)。 これは、core.autocrlfの 'input'および 'false'設定について同じことを文書化しようとするマトリックスで、行末の変換動作が不明な疑問符が付いています。 私の質問は: 疑問符はどうあるべきですか? このマトリックスは「非疑問符」に対して正しいですか? コンセンサスが形成されたように見えるので、回答から疑問符を更新します。 core.autocrlf値 true入力false -------------------------------------------------- -------- コミット| 変換しますか?? 新しい| LFに変換(LFに変換?)(変換なし?) コミット| に変換 ?番号 既存| LF(LFに変換?)変換 チェックアウト| に変換 ?番号 既存| CRLF(変換なし?)変換 私は実際にはさまざまな設定の長所と短所についての意見を探しているのではありません。私はgitが3つの設定のそれぞれで動作することを期待する方法を明確にするデータを探しています。 - アップデート04/17/2012:コメントでJJDによってリンクされたTim Clemによる記事を読んだ後、上記の表の「不明」値の一部の値を変更し、「既存のチェックアウト|変換してtrue」を変更しましたクライアントに変換する代わりにCRLFに変換します。」彼の定義は次のとおりです。これは、他のどこかで見たものよりも明確です。 core.autocrlf = false これはデフォルトですが、ほとんどの人はこれをすぐに変更することをお勧めします。falseを使用した結果、Gitがファイルの行末を混乱させることはありません。LF、CRLF、CR、またはこれら3つのランダムな組み合わせでファイルをチェックインできますが、Gitは関係ありません。これはdiffを読みにくくし、マージをより困難にする可能性があります。Unix / Linuxの世界で働いているほとんどの人は、CRLFの問題がなく、ファイルがオブジェクトデータベースに書き込まれたり、作業ディレクトリに書き込まれたりするたびにGitが余分な作業を行う必要がないため、この値を使用します。 core.autocrlf = true つまり、Gitはすべてのテキストファイルを処理し、そのファイルをオブジェクトデータベースに書き込むときにCRLFをLFに置き換え、作業ディレクトリに書き込むときにすべてのLFをCRLFに戻すことを確認します。これは、作業ディレクトリにCRLFを保持しながらリポジトリを他のプラットフォームで使用できるようにするため、Windowsで推奨される設定です。 core.autocrlf =入力 …
220
git
newline
core.autocrlf