GITリポジトリでCRLFを修復してマージの競合を回避する方法

Question

autocrlf=trueでレポを作成した後、チェックアウトを行い、autocrlf=falseでコミットしました。その後、autocrlf=true（OS Win）に切り替えました。 私はブランチ間でいくつかのマージを始めるまで、すべてがOKであるようでした。 eolsが変更されたために、ファイル全体が変更されたとマークされたマージ競合が多数発生しました（チェックアウトされたファイルで、autocrlf=falseとコミットしたと仮定します）。

私には価値のある歴史があるので、新しいrepoを作成して新しい人生を始める代わりに、変換済みのコミットを修正するか、eolsに変換することをお勧めします。

これは私が理解する方法であるautocrlf（OS勝利）：

場合ので、私はautocrlf=falseとGITを使用したい今autocrlf=false

WorkingTree -> commit -> GITRepository 
CRLF   no conv.  CRLF 
LF   no conv.  LF 
WorkingTree <- checkout <- GITRepository 
CRLF   no conv.  CRLF 
LF   no conv.  LF 

場合場合

WorkingTree -> commit -> GITRepository 
CRLF   CRLF to LF  LF 
LF   no conv.  LF 
WorkingTree <- checkout <- GITRepository 
CRLF   LF to CRLF  LF 

autocrlf=true場合私は各支店をチェックアウトすることに決めました。とcomでソースファイルのeolsを修復しました。 CRLFでミットバック。私はそれをしましたが、時間がたってもまだautocrlfの設定をfalseに変更した後にチェックアウトされなかったファイルが残っています（またはこれらのファイルが古いコミットから継承されるようになりましたか？すべてのLFからCRLFへの処理を自動化するので、私にとってはそのような状況について他の説明はありません）。 私はまたファイルをtouchにしようとしましたが、それらをすべて再コミットしました（私はここのどこかでstackoverflowで見たように）。しかし、日付の変更はGIT AFAIKには関係ありません。 How to undo the damage of autocrlfも読んだことがありますが、それが私の場合であるかどうかわかりませんし、ウィザードのトリックも理解できません。

どうすればこの混乱から逃れることができますか？

Answer 1

「再帰的」戦略にgit mergeオプション「ignore-space-change」または「ignore-all-space」を使用します。このオプションは少なくとも1.7.4.1にあります。

Answer 2

簡単な答え：Windows以外のプラットフォームでx-platform devを実行している場合を除き、これをfalseに設定してください。あなたのソース管理があなたのためにファイルを束縛する必要はありません。残っている問題を修正したら、あなたは飛行すべきです。あなたと一緒に働いている他の人もこれをfalseに設定してください。