0

メイン（および唯一の）ブランチにいくつかの変更（A）を加えました。次に、同僚がいくつかの変更を加えました (B)。その後、変更 (A) が絶望的に​​壊れていることがわかり、完全に破棄することにしました。一方、変更 (B) はまったく問題なく、幸いにも変更 (A) から完全に独立しています。変化 (B) は変化 (A) よりもはるかに小さい。

通常、ここで説明したとおりhg commit --close-branchにします。しかし、その後、変更が失われ (B)、新しいアクティブ ブランチでそれらを再作成する必要があります。影響を受けるファイルを（手動で）特定し、それらを（手動で）更新してからコミットするだけで、それを行うことができます。これは明らかに完全ではありません。これには 2 つの手動の手順が必要であり、リポジトリに誤解を招くコミットも作成されます (変更は少し前に同僚によって行われたため、誤解を招く可能性がありますが、今日は私によって行われたように見えます)。世界の終わりではないと思いますが、もっとエレガントな解決策はありますか?

注: Mercurialがリビジョン ツリー内の 1 つのコミットから別の場所への違いのみの適用をサポートしていれば、機能していたはずです。しかし、正当な理由から、この機能は存在しないのではないかと思います。差分と既存の親チェンジセットが別の親チェンジセットに逐語的に適用されたときに役立つことは非常にまれです。

4

1 に答える 1

4
  1. --close-branch悪い変更セットを破棄するよりも、別の根拠があります
  2. 「undoing-changeset」を提供することにより、以前の履歴で提示された変更セットを元に戻すことができます。読み取りhg help backout、一般的なhg backout CSET-HASH逆の変更で、リポジトリでの追加のコミットのコストで CSET-HASH で行われます。

古いチェンジセットの影響を殺すためにバックアウトを使用する例(rev. 7 undo rev.3)

>hg log -r 3:7 --template "{rev}:{node|short}\n{desc}\n\n"
3:2f09429039a6
Немного более русские даты

4:97419f57d7db
Заготовки под перевод

5:674a76db96fd
UTF8 и перевод assigncategories

6:9cd6b52df09f
Подчистки локализации

7:c2a2812d11ad
Backed out changeset: 2f09429039a6
  1. ブランチ間で変更セットをチェリーピックし、読み取ることができhg help graftます( old の代わりに挿入するマージベースのロジックhg transplant)。有用か無用かは人間の選択の問題であり、新しい親の上に移植された変更セットの実行可能性 (マージ競合なし) は移植自体の責任です

グラフト マージで競合が発生した場合、現在のマージを手動で解決できるように、グラフト プロセスが中断されます。

于 2012-12-02T06:02:09.713 に答える