リビジョン 24 で、私は新しい機能のブランチを作成しました。その間、他の人々はデフォルト (リビジョン 26、28、および 29) で作業を続けましたが、プロジェクトは悪い状態のままになりました。私はブランチ (rev 36 まで) で開発を続けましたが、これがデフォルトのブランチになるはずです。それ、どうやったら出来るの？
デフォルトで 24 に戻して 36 とマージしようとしたところ、希望どおりデフォルトで 37 になりました。しかし、今では 2 つの頭 (37 と 29) があると文句を言っています。26、28、および 29 はダメなので、マージしたくありません。37 に行って hg merge --tool internal:local -r 29 を実行して 29 を破棄しようとしましたが、うまくいきませんでした。
これは本当に単純なようですが、ちょっと行き詰まっています。
前もって感謝します
これを解決する 1 つの方法は、不要なブランチを単純に閉じることです。
hg update 29
hg commit --close-branch -m "closing branch"
技術的には、まだ 2 つのヘッドがありますが、1 つが閉じているとマークされるため、一般的な使用 (たとえば、 を実行した場合) では気付かないでしょうhg heads。
あるいは、水銀が「頭が2つあることに不満を持っている」と述べているのは、別のリポジトリにプッシュしようとしているときだと思います。この場合、はい、実際には新しいヘッドについて知っており、それが存在することを受け入れると指定できます。ブランチをクローズ済みとしてマークした後にこれを行う場合、問題は発生しません。
hg push --force
ただし、更新を行うとあいまいになる可能性があるため、その場合はリビジョンを指定することをお勧めします。
最後に、自分のブランチにマージしていない変更セットを表示したくない場合は、新しいリポジトリにクローンするときに自分の最新のリビジョンを指定できます。
hg clone project new_project --rev 37
これにより、そのリビジョンに到達するために必要な変更セットだけのクローンが作成されると思います。その後、これを作業の基礎として使用できます。欠点は、実際に必要な祖先以外の変更セットがないことです。
他のオプションについては、Mercurial にパッケージ化されている拡張機能のいくつかを調べますstrip。私はこれを使用していないので、それについてのアドバイスはできません。
詳細については、こちらを参照してください。
クラウディオ、私はあなたの質問をよりきれいな形に「翻訳」しようとします（必要に応じて翻訳と修正を確認してください）
rev 24で名前付きブランチに匿名ブランチを作成defaultしましたが、開発で別のツリーからいくつかの変更セットのみを使用したいと考えており、リモート サーバーへのプッシュで問題が発生し、追加のヘッドの作成に関する苦情がありました。
私の再構築は正しいですか？
「はい」で不要な変更セット 26、28、29 が単一の連続した範囲内にある場合、「最後に有効な」外部変更セットでマージできます (24 のマージは役に立たず、glog なしの AFAICS - 分岐点のように見えます)。不要なヘッドを閉じます: @icabod は--close-branch レシピで修正
反対側から、リポジトリが一意で公開されていない場合は、履歴を書き換えて (MQ: strip、histedit...)、マージする前に悪い変更セットを削除し、クリーンな 2 番目の匿名ブランチを取得し、マージ、コミット、プッシュします。
また、（推奨されていませんが）push -f両方のヘッドをリモートレポにプッシュすることもできます。あなたと他の人がそれで作業している間、あなたのヘッドはアクティブになります
コメント pic でクリアされた問題を修正
修正された再構成、反復 2: デフォルト ブランチに変更セットがいくつかあります。これらの変更をメインラインから除外し、ブランチをデフォルトにマージします。
提案された以前の履歴の書き換え (履歴からの変更セットの完全な削除 - 「未公開」リポジトリに適用可能) を除いて、履歴に悪い変更セットを残すことができますが、追加の変更セットのコストでそれらの変更を元に戻すことができます:hg backout -r REV変更セットの作成、REV からの変更の元に戻す (できます)ここで revrange を使用したことを思い出さないでください)。デフォルトで 3 つ (最大) の新しい backout-changeset があり、ブランチをデフォルトにマージする準備ができています (マージ後でもバックアウトできます)。
基本的に、（a）defaultリビジョン24の状態に（履歴を破棄せずに）復元してから、（b）機能ブランチをデフォルトにマージする必要があります。デフォルトで2つのヘッドを作成することで少し複雑になりますが、大したことはありません。一歩ずつ進めていきましょう。
（安心して実験できるように、リポジトリ全体のクローンを作成することをお勧めします。気に入らないことをした場合は、ディレクトリ全体を削除して最初からやり直してください）。
誤った変更の影響を元に戻す方法は次のstripとおりです（履歴を破壊的に書き換えるようなコマンドを使用せずに）。
デフォルトの先頭に更新：
hg update -r 29
「現在の」リビジョンを変更せずに、すべてのファイルをリビジョン24のファイルに切り替えます。
hg revert -r 24
defaultこのファイルの状態を：の新しいヘッドとしてコミットします。
hg commit -m "Backing out revisions 26,28,29"
この時点で、defaultすべての間違った変更が取り消されているため、機能ブランチをの新しいヘッドにマージすることができます。
hg merge feature
これで話は終わりです。ただし、すでにfeaturerev 24にマージされ、revset 37が取得されています。問題ありません。手順1〜3を実行できます。これにより、破壊的な変更を行わずにデフォルトのヘッドが得られます。次に、のヘッドをマージする代わりに、最後のステップとしてマージしますfeature。37
hg merge -r 37
defaultこれにより、誤った変更をすでに取り消しているため、悪影響を与えることなく、の頭が統一されます。