web-dev-qa-db-ja.com

Gitでcore.autocrlf = trueを使うべきなのはなぜですか？

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

  1. どこでもcore.autocrlfをfalseに設定します。

  2. 指示に従って ここ （GitHubのヘルプページでエコーされている）リポジトリをLF行末だけを含むように変換し、その後Windowsではcore.autocrlfをtrueに設定し、OS Xではinputを設定します。これを行う際の問題は、リポジトリにバイナリファイルがある場合、次のようになることです。

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

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

それでは、なぜGitの行末変換をオフにしないでください。 core.autocrlfをオフにして問題を引き起こすことについての曖昧な警告がウェブ上にたくさんありますが、非常に少数の特定のもののものです。私がこれまでに発見した唯一のことは、kdiff3がCRLFの終わりを扱うことができないこと（私にとっては問題ではない）と、テキストエディタによっては行末の問題があること（私にとっても問題ではない）です。

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

改行コードをそのままにしておくことに他の問題はありますか。

gitline-endings
255
Rich

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

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

はがネイティブEOLを扱う必要があるという特別な扱いを見ることができないのであれば、 autocrlfをfalse のままにすることをお勧めします。

この設定はlocalになることに注意してください（configはリポジトリからリポジトリへプッシュされないため）。

そのリポジトリを複製するすべてのユーザーに同じ設定が欲しい場合は、CRLF属性を使用して、 " gitでのtext処理の最良の戦略は何ですか？ " .gitattributes file 。

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

190
VonC

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

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

すべての開発者がtrueに設定されていない場合はどうなりますか。1人の開発者が最終的にtrueに設定されます。これはあなたのリポジトリのすべてのあなたのファイルの行末をLFに変え始めます。また、ユーザーがfalseに設定した場合は、Visual Studioによって警告が表示され、変更するように求められます。あなたは2つのことが非常に早く起こるでしょう。 1つは、これらの警告がますます発生することです。チームが大きくなればなるほど、それだけ多くの警告が表示されます。 2番目の、そしてさらに悪いことに、それは修正されたすべてのファイルのすべての行が変更されたことを示すということです（すべての行の行末が真の男によって変更されるため）。最終的には、リポジトリの変更を確実に追跡することはできなくなります。誰もが偽りを保つことを試みるよりも、誰もが真実を保つようにする方がはるかに簡単でクリーンです。あなたの信頼できるソース管理がしてはいけないことをしているという事実を持って生きることと同じくらい恐ろしいです。今まで.

29
JGTaylor

更新：

注：Git 2.8以降、VonCによって指摘されたように、 /willnotのようにマージマーカーを使用すると、Windows形式のファイルにUnix形式の行末が導入されます 。

オリジナル：

私がこの設定で気付いたのは、マージの競合があると、gitが追加した違いによって、notが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

*それは実際には「メリット」という用語に値しません。

12
Rich