Gitでcore.autocrlf = trueを使用する必要があるのはなぜですか？

WindowsとOS Xの両方からアクセスできるGitリポジトリーがあり、CRLF行末のファイルが既にいくつか含まれていることを知っています。私の知る限り、これに対処するには2つの方法があります。

1. 設定するcore.autocrlfにはfalse、どこにでも

2. 指示に従ってくださいここだけLF行末を格納するリポジトリを変換するには（GitHubののヘルプページにエコー）、およびその後の設定core.autocrlfにtrueWindows上およびinputOS X上でこれを行うことに伴う問題は、私は、リポジトリ内の任意のバイナリファイルを持っている場合ということですそれ：

   1. gitattributesでバイナリとして正しくマークされていない、および
   2. CRLFとLFの両方が含まれている

   それらは破損します。リポジトリにそのようなファイルが含まれている可能性があります。

では、なぜGitの行末変換をオフにすべきではないのでしょうか。core.autocrlfスイッチをオフにしたことで問題が発生することについて、ウェブ上では漠然とした警告がたくさんありますが、特定の警告はほとんどありません。私がこれまでに見つけた唯一のことは、kdiff3がCRLFエンディングを処理できない（私にとっては問題ではない）ことと、一部のテキストエディターに行末の問題がある（私にとっても問題ではない）ことです。

リポジトリは私の会社の内部にあるので、異なるautocrlf設定や行末の要件を持つ人々とリポジトリを共有することを心配する必要はありません。

行末をそのままにしておくことに他に問題はありますか？

に設定autocrlfする特定の理由trueは次のとおりです。

• 避けるgit statusなど、すべてのファイルを示すmodifiedため、Windowsの一つにUnixベースのEOLのGitリポジトリのクローンを作成する際に行う自動EOL変換のを（参照問題83インスタンス用の）
• そして、あなたのコーディングツールが何らかの形で依存するネイティブファイルでのEOLスタイルビーイングの存在：
  • たとえば、ネイティブEOLを検出するようにハードコードされたコードジェネレーター
  • 正規表現またはコードがネイティブEOLを検出するように設定された他の外部バッチ（リポジトリの外部）
  • 一部のEclipseプラグインは、プラットフォームに関係なくCRLFでファイルを生成できると考えています。これは問題になる可能性があります。
  • Notepad.exe を使用してコーディングします（Windows 10 2018.09+を使用している場合を除き、メモ帳は検出されたEOL文字を尊重します）。

ネイティブのEOLを処理する必要がある特定の処理を確認できない場合は、（）に任せるautocrlffalseほうがよいでしょうgit config --global core.autocrlf false。

この構成はローカル構成になることに注意してください（構成がリポジトリからリポジトリにプッシュされないため）

そのリポジトリのクローンを作成するすべてのユーザーに同じ設定が必要な場合は、ファイルの属性を使用して、「gitでの最適なCRLF処理方法は何ですか？」を確認してください。text.gitattributes

例：

*.vcproj    text eol=crlf
*.sh        text eol=lf

注：git 2.8（2016年3月）以降、マージマーカーはCRLFファイルに混合行末（LF）を導入しなくなりました。「「<<<<<<< HEAD」マージ行でGitにCRLFを使用させる
」を参照してください。

私は.NET開発者であり、GitとVisual Studioを何年も使用しています。私の強力な推奨事項は、行末をtrueに設定することです。そして、リポジトリの存続期間中にできる限り早くそれを実行してください。

そうは言っても、Gitが行末を変更するのは嫌いです。ソース管理は、私が行う作業を保存および取得するだけで、変更することはできません。ずっと。しかし、そうです。

すべての開発者がtrueに設定されていない場合は、最終的に1人の開発者がtrueに設定されます。これにより、リポジトリ内のすべてのファイルの行末がLFに変更されます。また、ユーザーがfalseに設定した場合、それらをチェックアウトすると、Visual Studioから警告が表示され、変更するように求められます。あなたは2つのことが非常に速く起こるでしょう。1つは、これらの警告がますます多くなることで、チームが大きくなるほど多くの警告が表示されます。2つ目、さらに悪いことに、変更されたすべてのファイルのすべての行が変更されたことが示されます（すべての行の行末が本当の人によって変更されるため）。最終的には、レポの変更を確実に追跡できなくなります。全員を偽りにしようとするよりも、誰もが真実を保つようにする方がはるかに簡単でクリーンです。信頼できるソース管理がすべきでないことをしているという事実に耐えるのは、恐ろしいことです。ずっと。

アップデート2：

Xcode 9は、ファイルの現在の行末を無視する「機能」を備えているように見えます。代わりに、ファイルに行を挿入するときにデフォルトの行末設定を使用すると、行末が混在するファイルになります。

このバグはXcode 7には存在しなかったと確信しています。Xcode 8については不明です。良いニュースは、Xcode 10で修正されたようです。

それが存在していた間、このバグは私が質問で参照するコードベースに少量の陽気さを引き起こし（今日ではこれを使用していますautocrlf=false）、多くの「EOL」コミットメッセージにつながり、最終的にはgit pre-commitフックを作成して確認しました混合行末の導入を防止します。

更新：

注：VonCで指摘されているように、Git 2.8以降、マージマーカーはUnixスタイルの行末をWindowsスタイルのファイルに導入しません。

オリジナル：

この設定で気付いた小さな問題は、マージの競合がある場合、gitが追加した行に違いをマークアップすることで、ファイルの残りの部分があったとしてもWindowsの行末がないため、結果的に行末が混在しているファイルの場合、例：

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

これで問題が発生することはありませんが（両方のタイプの行末を処理できるツールであれば、行末が混在している場合にも対応できると思います-私たちが使用しているすべての行末は、確かにそうです）、それは注意すべきことです。

その他に、^*を使用git diffして、Windowsの行末を持つファイルへの変更を表示すると、追加された行に改行が表示されるため、次のようになります。

    // Not changed

+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{*「問題」という用語にはあまり意味がありません。}