6

複雑なhgリポジトリで複雑なマージを実行しようとしています。Mercurialがマージを実行するための「ベース」として使用することを選択した「最新の共有祖先」には満足していません。

ベースとして使用するために、自分で選択した特定のコミットを指定したいと思います。

これは可能ですか？もしそうなら、どのように？

4

3 に答える 3

15

Mercurial 3.0：マージベースとして使用する祖先を選択できるようになりました。を設定することでそれを行いますmerge.preferancestor。これが理にかなっているとき、Mercurialはそれについてあなたに話します。以下の例では、次のようになります。

$ hg merge
note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
      alternatively, use --config merge.preferancestor=fdf4b78f5292
merging x
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

バージョン3.0より前のMercurial： Lazy Badgerは正しいので、コマンドラインから使用するときにMercurialが選択した祖先を選択することはできません。ただし、これは内部で行うことができ、このための拡張機能を作成することはそれほど難しくありません。

from mercurial import extensions, commands, scmutil
from mercurial import merge as mergemod

saved_ancestor = None

def update(orig, repo, node, branchmerge, force, partial, ancestor=None):
    if saved_ancestor:
        ancestor = scmutil.revsingle(repo, saved_ancestor).node()
    return orig(repo, node, branchmerge, force, partial, ancestor)

def merge(orig, ui, repo, node=None, **opts):
    global saved_ancestor
    saved_ancestor = opts.get('ancestor')
    return orig(ui, repo, node, **opts)

def extsetup(ui):
    extensions.wrapfunction(mergemod, 'update', update)
    entry = extensions.wrapcommand(commands.table, 'merge', merge)
    entry[1].append(('', 'ancestor', '', 'override ancestor', 'REV'))

これをファイルに入れて、拡張子をロードします。これで使用できます

hg merge --ancestor X

通常の祖先をオーバーライドします。ご存知のように、いくつかの可能な祖先がある場合、これは違いを生みます。この状況は、クロスクロスマージがある場合に発生します。次のコマンドを使用して、このようなケースを作成できます。

hg init; echo a > x; hg commit -A -m a x
hg update 0; echo b >> x; hg commit -m b
hg update 0; echo c >> x; hg commit -m c
hg update 1; hg merge --tool internal:local 2; echo c >> x; hg commit -m bc
hg update 2; hg merge --tool internal:local 1; echo b >> x; hg commit -m cb

グラフは次のようになります。

@    changeset: 4:333411d2f751
|\
+---o  changeset: 3:7d1f71140c74
| |/
| o  changeset: 2:fdf4b78f5292
| |
o |  changeset: 1:eb49ad46fd72
|/
o  changeset: 0:e72ddea4d238

通常どおりにマージするeb49ad46fd72と、祖先としてチェンジセットが取得され、ファイルには次のものxが含まれます。

a
c
b
c

代わりに使用hg merge --ancestor 2すると、異なる結果が得られます。

a
b
c
b

どちらの場合も、私のKDiff3は、競合を報告することなく、マージを自動的に処理できました。「再帰的」マージ戦略を使用しe72ddea4d238て祖先として選択すると、賢明な対立が発生します。Gitはデフォルトで再帰的マージ戦略を使用します。

于 2012-02-24T12:29:57.637 に答える
1

Baseは、マージツールへの別の入力として使用されます。マージツールの構成を無効premergeにし（競合がない場合、premergeが「明白な選択」を行います）、マージツールを手動で呼び出して、ローカル、リモート、およびベースとして必要な3つのリビジョンのコピーを提供すると、何でも取得できます。マージツールで必要です。マージに実際に記録されるのは、左の親と右の親だけです。

于 2012-02-19T17:24:05.153 に答える
-1

あなたはそれをすることはできません。最新の共有祖先がマージの実際のベースであるため

マージを実行したいが、再考したくない場合（logic-base show / me /の仮定とsolution-pathが間違っているため）、clone-rebase-merge-export-importパッチルートに移動できます。

于 2012-02-19T16:55:47.847 に答える