75

gitのCrLf設定に関連する複雑さを理解していません：core.autocrlf、core.safecrlf

私はチームでクロスプラットフォームプロジェクトを開発しており、WindowsとLinuxの両方の開発者が、行末のスタイルのためにファイルを変更済みとしてgitマークすることなく共同作業できるようにしたいと考えています。

さまざまな設定はどういう意味ですか？オプションのいずれかを選択した場合の結果はどうなりますか？そして、私の場合の最良の解決策は何でしょうか？

はい、私はこの質問を知っています、そしてそこでの答えは洞察に満ちていなかったので、役に立ちませんでした。

4

3 に答える 3

100

の3つの値autocrlf：

  • true-コンテンツがリポジトリに入る（コミットされる）と、その行末はLFに変換され、コンテンツがリポジトリから出る（チェックアウトされる）と、行末はCRLFに変換されます。これは一般的に、無知なWindowsユーザー/編集者を対象としています。編集者（またはユーザー）がCRLFエンディングのファイルを作成し、通常のLFエンディングが表示されるとびっくりするが、リポジトリにLFエンディングが必要な場合は、これでカバーできると思います。ただし、問題が発生する可能性はあります。リンクされた質問には、偽のマージ競合の例と変更されたファイルのレポートがあります。

  • input-コンテンツがリポジトリに入ると、その行末はLFに変換されますが、コンテンツは途中で変更されません。これは基本的にと同じ領域にありtrueますが、編集者が実際にLFエンディングを正しく処理できることを前提としています。CRLFで終わるファイルを誤って作成する可能性を防ぐだけです。

  • false--gitは行末をまったく処理しません。それはあなた次第です。これは多くの人がお勧めするものです。この設定では、ファイルの行末が混乱する場合は、そのことに注意する必要があるため、マージの競合が発生する可能性ははるかに低くなります（情報に通じたユーザーを想定）。エディター/IDEの使用方法について開発者を教育することで、問題をほぼ解決できます。私が見たプログラマー向けに設計されたすべてのエディターは、適切に構成されていればこれに対処できます。

すでにリポジトリにautocrlfあるコンテンツには影響しないことに注意してください。以前にCRLFエンディングで何かをコミットしたことがある場合、それらはそのまま残ります。これは、autocrlfに依存することを避ける非常に良い理由です。1人のユーザーが設定していない場合、CRLFで終わるコンテンツをリポジトリに取り込むことができ、それが維持されます。正規化を強制するためのより強力な方法は、text属性を使用することです。gitがコンテンツがテキスト（バイナリではない）であると判断した場合、特定のパスに対してこれを設定すると、行末の正規化のマークが付けられます。auto

関連するオプションはですsafecrlf。これは基本的に、バイナリファイルでCRLF変換を不可逆的に実行しないようにするための単なる方法です。

私はWindowsの問題やgitを扱った経験があまりないので、影響や落とし穴についてのフィードバックは大歓迎です。

于 2010-11-15T07:38:21.603 に答える
12

コミットとチェックアウトのケースで考えられる3つの値を調べました。これは、結果の表です。

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

core.autocrlf = inputすべてのプラットフォームで使用することをお勧めします。この場合、Gitが直面CRLFすると、暗黙的にGitがに変換されLF、既存のファイルはLFそのまま残ります。

于 2016-12-22T11:48:34.543 に答える
4

参考までに、デフォルトでは、Windowsで終わる行はCRLFを取り、LinuxはLFを取ります。明確に理解するために、以下の表を見つけてください。

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║    false     ║    input     ║    true      ║
║               ║ Win => Unix  ║ Win => Unix  ║ Win => Unix  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ *CRLF => LF  ║ *CRLF => LF  ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ *LF => CRLF  ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

上記の表形式の情報で、記号*はWindowsとUnixの違いを強調しています。一目で、以下はOSプラットフォームに基づくCLRF情報です。

Windowsユーザーの場合

  • クロスプラットフォームプロジェクトで作業しているWindowsユーザーの場合、WindowsマシンとUnixマシン用である必要があります。core.autocrlf=truecore.autocrlf=input
  • WindowsユーザーがWindowsプロジェクトのみを操作する場合は、両方core.autocrlf=trueまたはcore.autocrlf=false。ただしcore.autocrlf=input、この場合は問題が発生します。

Unixユーザーの場合（Linux / Mac OS）

  • クロスプラットフォームプロジェクトで作業しているUnixユーザーの場合、WindowsマシンとUnixマシン用である必要があります。core.autocrlf=truecore.autocrlf=input
  • UnixユーザーがUnixプロジェクトのみを操作する場合は、両方core.autocrlf=inputまたはcore.autocrlf=false。ただしcore.autocrlf=true、この場合は問題が発生します。

同じOSユーザーの場合

  • 純粋なWindowsプロジェクトまたは純粋なUnixプロジェクトの場合は、になりますcore.autocrlf=false。
于 2017-07-03T22:12:34.240 に答える