git merge
は行末の違いを無視できますか?
たぶん私は間違った質問をしています...しかし:
Uisng config.crlf input
を試しましたが、特に適用したときに、物事が少し面倒で制御不能になりました事後。
1つには、このオプションを適用する前にリポジトリにコミットされたファイルに事実の後にこの設定を適用しても影響がないようです。別のことは、突然すべてのコミットがCRLFがLFに変換されることに関する多くの迷惑な警告メッセージをもたらすことです。
正直に言うと、行末がどのように使用されるかはあまり気にしません。個人的にはUnixスタイル\n
を好みますが、何でも。私が気にするのは、git merge
を少し賢くして、行末の違いを無視することです。
2つの同一のファイルがある場合もありますが、gitはそれらが競合しているとマークします(そして、競合はwholeファイルです)。
git diff
は--ignore-space-at-eol
オプションを受け入れますが、git merge
もこのオプションを使用することはできますか?
私は同じ答えを探していましたが、私は this を見つけました
異なるチェックイン/チェックアウト属性を持つブランチのマージ
Clean/smudgeフィルターやtext/eol/ident属性を追加するなど、そのファイルの正規リポジトリ形式を変更させる属性をファイルに追加した場合、属性が設定されていない場所をマージすると、通常はマージの競合が発生します。
これらの不要なマージの競合を防ぐため、merge.renormalize構成変数を設定することにより、3者間マージを解決するときに、ファイルの3つのステージすべての仮想チェックアウトとチェックインを実行するようにgitに指示できます。これにより、変換されたファイルが未変換のファイルとマージされるときに、チェックイン変換によって引き起こされる変更が誤ったマージ競合を引き起こすことを防ぎます。
"smudge→clean"の結果が既に汚れているファイルでも "clean"と同じ出力になる限り、この戦略はすべてのフィルター関連の競合を自動的に解決します。この方法で動作しないフィルターは、手動で解決する必要がある追加のマージ競合を引き起こす可能性があります。
したがって、このコマンドを任意のリポジトリで実行すると、トリックが実行されます。
git config merge.renormalize true
https://stackoverflow.com/a/12194759/1441706 および https://stackoverflow.com/a/14195253/1441706 を読んだ後
私にとって、このコマンドは完璧にトリックを行いました:
git merge master -s recursive -X renormalize
この答えのように: https://stackoverflow.com/a/5262473/943928
試すことができます:git merge -s recursive -Xignore-space-at-eol
「git merge -Xrenormalize」は魅力のように機能します。
私がやったことは、すべてをデフォルトのままにして(つまりautocrlf = true)、すべてのファイルをタッチし(。-exec touch {} \;を見つけます)、gitにそれらを「変更された」と認識させてコミットし、それで完了です。そうしないと、迷惑なメッセージや驚くべき違いに悩まされるか、gitの空白機能をすべてオフにする必要があります。
非難情報は失われますが、後で行うよりも早く行うほうがよいでしょう:)
http://stahlforce.com/dev/index.php?tool=remcrlf
私はそれを試してみましたが、コードの最後の行の後にCRLFがない場合は、LFが追加され、gitでファイルが変更されます。それ以外は動作します。
これを直接実行できるようには見えませんが、この投稿では回避策を提案しています。
AFAICT、(私は試していません)git diff
を使用して、マージするブランチを共通の祖先と比較し、git apply
で結果を適用できます。両方のコマンドには、行末エラーと空白エラーを無視する--ignore-whitespace
オプションがあります。
残念ながら、パッチがきれいに適用されない場合、操作全体が中止されます。マージの競合を修正することはできません。 --reject
ファイルにパッチできないハンクを残す.rej
オプションがありますが、これは1つのファイルにマージの競合が表示されるのと同じではありません。
最良の方法は、両方のブランチの行末をマージする前に正規化する(そしてコミットする)ことであるように思えます。
「crlfをlfに変換」をグーグルで検索し、最初の結果としてこれを見つけました。
http://stahlforce.com/dev/index.php?tool=remcrlf
私はそれをダウンロードして使用しましたが、すてきなツールのようです。
>sfk remcr . .py
ただし、ディレクトリとファイルタイプ(例:.py)を指定しないと、.git
ディレクトリの内容を混乱させようとする可能性があります。