3

新しいリポジトリ を作成し、test-backoutそこに新しいファイル を追加しましたfile。次に、毎回 4 つのコミットを行い、file使用するコミットの数を追加します。

echo [manually entered number] >> file
hg commit -m '[manually entered number]'

実際には、ファイルには次のものが含まれていました。

init
1
2
3

hg book によると、 を実行すると、次のようhg backout --merge 2になります。

init
1
3

しかし、代わりに、マージに失敗し、difftool (vimdiff) が開き、3 つのオプションが表示されます。

init          | init          | init
1             | 1             |
2             |               |
3             |               |

私は最初にオプションを付けて試しましたが、--mergeオプションを付けずにもう一度試しました。私の質問は今、私が得る方法がまだありますか？

init
1
3

間違いを犯したり、何かを見逃したりしただけですか、それともそれらのオプションにこだわっていますか?

4

1 に答える 1

7

3ウェイマージを取得した大きな要因は、コンテキストがあまりにも人工的であるということです。これについては説明します。

50行のテキストファイルを取得して別の部分を変更し、各変更をコミットする場合、競合を解決する必要はありません。つまり、4つのチェンジセットがあります。rev0はファイルを追加し、rev 1、2、および3はそれぞれ、ファイルの1つの領域（開始、中間、または終了）を変更します。

この状況では、実行hg backout 2すると、rev 2の逆になり、それらの変更が作業ディレクトリにマージされます。コミットすると、グラフは線形になります。

@  backout 2
|
o  3
|
o  2
|
o  1
|
o  initial

代わりに実行hg backout 2 --mergeすると、バックアウトするリビジョンの子としてバックアウトが自動的にコミットされ、それをチップとマージして、マージをコミットした後に分岐グラフが生成されます。

@    merge
|\
| o  backout 2
| |
o |  3
|/
o    2
|    
o    1
|    
o    initial

どちらの状況でも、3方向のマージを行う必要はありませんでした。自動的に取得されない理由

init
1
3

代わりに、3方向のマージを行う必要があります。それは、変更が近すぎるということです。各チェンジセットのコンテキストと変更は完全にオーバーラップしています（diffチャンクのコンテキストのデフォルトの行数は3行で、これは4番目のチェンジセットにあるファイル全体を含みます）。

同様の例は、それぞれが同じ行を変更した3つのチェンジセットがある場合です。ここで行っているように途中の変更を取り消すと、3方向のマージが表示されますが、正しくするには手動で編集する必要があります。

ちなみに、hg help backout次のように証明されているように、動作は1.7で変更されました。

バージョン1.7より前では、-mergeを使用しない場合の動作は、-mergeの後に「hgupdate--clean」を指定するのと同じでした。マージをキャンセルし、REVの子を個別にマージされるヘッドとして残します。

しかし、それはあなたが疑ったことではないと思います。

于 2011-08-17T05:05:32.907 に答える