Mercurialで祖先とのマージが可能なのはなぜですか？

Question

私はthis repo historyに困惑しています。このページでは、小さなブランチfile-contentが表示されます。これは、ブランチdefaultにマージされていますが、一方のヘッドはもう一方の祖先であったにもかかわらず、マージされています。私は似た何かをしようとすると、

は、私は私の周りではなく、他の方法（クローズドブランチヘッドに先祖からマージアボート側枝が閉じている

1. ない限り、メッセージと
2. を取得します）。 （file-contentブランチが閉じていない、非アクティブとマークされ、このグラブレポで。）

編集：あなたは祖先と合併することができますその下で、実際の条件が私の答えで説明されています。

ここで何が起こっているのですか？

Answer 1

祖先とマージできないという技術的な理由はありません。あなたが見つけたように、Mercurialはそれをサポートしていることがあります。したがって、純粋にGUIの制限です。この背後にある理由は、hg updateがhg mergeと同じ結果を示す場合は、単純にするためにその代わりに使用する必要があります。

mergeは、3つのリポジトリ状態の組み合わせです：共通の祖先と、マージしている2つのチェンジセット。 3ウェイマージは、ハンクベースでハンクで行われます。リモートでローカルマージするための表では、次のようになります。そして、ancestor == localremoteの祖先である

ancestor local remote -> merge 
old  old old  old (nobody changed the hunk) 
old  new old  new (I changed the hunk) 
old  old new  new (you changed the hunk) 
old  new new  new (hunk was cherry picked onto both branches) 
old  foo bar  <!> (conflict, both changed hunk but differently) 

local場合。だから、テーブルは次のようになります。どちらの場合も

ancestor local remote -> merge 
old  old old  old (nobody changed the hunk) 
old  old new  new (you changed the hunk) 

、merge列はremote列であったものが含まれています。あなたの例では、localはdefaultとremoteですfile-contentです：

$ hg update default 
$ hg merge file-content 

結果はちょうどfile-contentように見えるマージチェンジセットです。

Answer 2

これは奇妙なことには文書化されていませんが、https://www.mercurial-scm.org/wiki/Mergeの下にあるリンクをたどると、祖先とのマージに対するルールの例外があります。私が最初に推測したように、子孫が閉じた枝である必要はありません。代わりに：あなたは先祖（つまり、作業ディレクトリが祖先ではなく、他のチェンジセットに更新する必要があります）

作業ディレクトリの親のどのとあなた」チェンジのブランチ名からマージする必要があります

1. 再統合は異なっていなければなりません。例えば。 1つはブランチ名default、もう1つはブランチ名feature-X

これは、新しいブランチを開始し、元のブランチで作業しなくてもそれを元に戻す機能です暫定的。