2

タイトルの通りです。これをグーグルで調べてみましたが、説明が見つからなかったので、洞察を提供するkdiff3のドキュメントを調べました。私が遭遇している状況は、あるブランチから別のブランチへのマージを行い、多数の競合を取得し、git mergetool を使用してそれらを 1 つずつ解決することです。何が起こるかというと、kdiff3 の起動時に一部のファイルで、自動解決された競合が x 個あり、競合が残っていないというダイアログが表示されるので、ファイルを保存して続行します。

kdiff3 のドキュメントによると、ファイルの 1 つのバージョンのみで行が変更された場合、競合は自動的に解決されます。すなわち。ベースはローカルまたはリモート ファイルと同じですが、両方ではありません。

私の質問は、私のマージツールがこれを自動解決できる場合 (私はいくつか試してみましたが、それらはすべていくつかの競合を自動解決します)、実際にそれが何をするかは論理的に思えますが、なぜ git から競合が発生するのでしょうか?

フォローアップの質問は次のとおりです。マージツールを開く前に、これらの競合をgitに自動解決させるにはどうすればよいですか?

例は次のとおりです。

base:
line 1
line 2
line 3

local:
line 1
line 2
line 3

remote:
line 1
line abc
line 3

上記の競合は Git では発生すると思いますが、kdiff3 では自動解決されます。別のケースかもしれませんが、以前に自動解決されたマージを行ったことがありますが、自動解決されてから正確なシナリオを思い出せません。

4

1 に答える 1

1

いくつかの理由が考えられますが、最も可能性が高いのはマージ設定の違いです。

kdiff3 が無視するように設定できる差異の例:

  • 空白: 空行と 4 つのスペースがある行
  • コメント:/* This is the original comment */と/* This is the modified comment */
  • 数字:number_of_diffs = 3とnumber_of_diffs = 7

これらのケースのそれぞれ (および場合によってはさらに多くのケース) で、kdiff3 は違いを無視するだけでよいため、マージに問題はありません。一方、Git では競合を手動で解決する必要があります。

あなたの例では、（合理的な）ツールがマージ競合を発行する明確な理由はありません。しかし、ベース ファイルが Linux で作成されていて、Windows でローカル ファイルを編集した場合 (またはその逆) はどうなるでしょうか。その後、おそらく、行末が変更されたでしょう。これはおそらく完全に見えませんが、マージの競合が発生します。試してみたところ、次の出力が得られました。

Auto-merging file.txt
CONFLICT (content): Merge conflict in file.txt
Automatic merge failed; fix conflicts and then commit the result.

次に実行しました：

$ git mergetool
merge tool candidates: meld opendiff kdiff3 tkdiff xxdiff tortoisemerge gvimdiff diffuse ecmerge p4merge araxis bc3 codecompare emerge vimdiff
Merging:
file.txt

Normal merge conflict for 'file.txt':
  {local}: modified file
  {remote}: modified file
Hit return to start merge resolution tool (kdiff3):

return を押すと、kdiff3 は静かに 2 つのファイルをマージし (開いているのを見たことさえありませんでした)、空白の違いを問題なく解決しました。

それはあなたのケースで正確に起こっていることではないかもしれませんが、空白のために kdiff3 が自動解決するものをマージできないという実際の例です。

于 2013-05-22T12:36:13.143 に答える