core.safecrlf
致命的なエラーではなく警告のみが必要な場合は、「警告」に設定することをお勧めします。
" git config
" 管理ページから:
core.safecrlf
true の場合、行末変換がアクティブなときに CRLF の変換が元に戻せるかどうかを git がチェックします。Git は、コマンドが作業ツリー内のファイルを直接または間接的に変更するかどうかを確認します。
たとえば、ファイルをコミットした後に同じファイルをチェックアウトすると、作業ツリーに元のファイルが生成されます。これが core.autocrlf の現在の設定に当てはまらない場合、git はファイルを拒否します。
この変数は "warn" に設定できます。この場合、git は元に戻せない変換についてのみ警告しますが、操作は続行します。
CRLF 変換では、データが破損する可能性がわずかにあります。
有効にすると、git はコミット時に CRLF を LF に変換し、チェックアウト時に LF を CRLF に変換します。
コミット前に LF と CRLF が混在するファイルは git で再作成できません。
テキスト ファイルの場合、これは正しいことです。行末を修正して、リポジトリに LF 行末のみが含まれるようにします。
ただし、誤ってテキストとして分類されたバイナリ ファイルの場合、変換によってデータが破損する可能性があります。
このような破損を早期に認識した場合は、変換タイプを で明示的に設定することで簡単に修正できます.gitattributes
。
コミットした直後は、作業ツリーに元のファイルが残っており、このファイルはまだ破損していません。このファイルがバイナリであり、git がファイルを適切に処理することを明示的に git に伝えることができます。
残念ながら、行末が混在するテキスト ファイルをクリーンアップするという望ましい効果と、バイナリ ファイルを破損するという望ましくない効果を区別することはできません。
どちらの場合も、CRLF は元に戻せない方法で削除されます。テキスト ファイルの場合、CRLF は行末であるため、これは正しいことですが、バイナリ ファイルの場合、CRLF を変換するとデータが破損します。
正確なファイルまたはファイルの種類を特定して、eol を.gitattributes
ファイルのみ (設定済みの設定で) に強制し、 falsecore.eol
のままにすることを好みます。autocrlf
eol が混在するテキスト フィールドの場合、このブログ投稿では、たとえば次のことを提案しています。
コンピュータに Notepad++ がインストールされている場合は、次の手順に従ってください。
- 致命的な問題が発生しているファイルを開きます。
- クリックし
Edit -> EOL Conversion
てから、Windows フォーマットまたはコミットに問題があるものを選択します。
Git 2.17 または 2.18 を使用している場合の警告: 8462ff4で導入されたリグレッション(" convert_to_git()
:safe_crlf/checksafe
はint conv_flags
"、2018-01-13、Git 2.17.0) が Git 2.17 サイクルに戻ったため、設定にもかかわらずautocrlf
、書き換えによって警告メッセージが生成されました。safecrlf=false
Anthony Sottile ( )によるコミット 6cb0912 (2018 年 6 月 4 日)を参照してください。( 2018 年 6 月 28 日、コミット 8063ff9でJunio C Hamanoによってマージされました)asottile
gitster