12

でレポを作成し、 でautocrlf=trueチェックアウトとコミットを行いましautocrlf=falseた。autocrlf=trueその後、 （OS Win）に戻りました。ブランチ間のマージを開始するまでは、すべて問題ないように見えました。多くのマージ競合が発生し、変更によりファイル全体が変更済みとしてマークされましたeols（チェックアウトされ、でコミットされたファイルだったと思いますautocrlf=false）。

私にとって価値のある歴史がいくつかあるので、eols新しいレポを作成して新しい生活を始めるよりも、何らかの変換を行うか、converted を使用してコミットを修正することを好みます。

これが私が理解している方法ですautocrlf（OS Win）：

ケースautocrlf=true

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

ケースautocrlf=false

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

で GIT を使用したいautocrlf=falseので、各ブランチをチェックアウトし、ユーティリティEOL コンバーターeolsでソース ファイルを修復し、CRLF でコミットすることにしました。私はそれを行いましたが、しばらくすると、設定をに変更した後にチェックアウトされなかったファイルがまだいくつかあります（または、これらのファイルは古い修正されていないコミットからマージされましたか？変換中にマスク *.filetype を使用して処理を自動化しました）すべての LF から CRLF への変換なので、このような状況について他に説明はありません)。また、ファイルをすべて再コミットしようとしましたが（ここでstackoverflowのどこかで見たように）、日付の変更はGIT AFAIKには関係ありません。autocrlfのダメージを元に戻す方法も読みましたautocrlffalsetouch、しかしそれが私の場合かどうかはわかりませんし、ウィザードのトリックも理解していません。

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

4

2 に答える 2

1

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

于 2011-09-22T18:38:08.743 に答える
-1

簡単な答え: Windows 以外で x-platform 開発を行っている場合を除き、これを false に設定します。ソース管理でファイルをろくでなしにする必要はありません。残りの問題を修正したら、飛行する必要があります。一緒に作業している他の人もこれを false に設定してください。

于 2011-12-29T20:05:41.000 に答える