私は、メインリポジトリと複数のサブリポジトリを備えた大規模なプロジェクトに取り組んでおり、次のように編成されています。
main-repo
sub-a
sub-b
sub-c
作業する各人は、独自の名前付きブランチを 1 つ以上持っています。私は私たちが呼ぶ支店で働いてshastings-devおり、同僚は私たちが呼ぶ支店を持っていますcoworker-dev。(これらのブランチは両方ともmain-repo、sub-a、およびにsub-b存在します。どちらにも存在せずsub-c、そのブランチには他の誰かのブランチを使用しています。)
coworker-dev私の問題は、どうにかして新しいヘッドを作成しないと、変更をマージできなくなったことです。この一連のコマンドには予期しない効果があります。
hg pull
hg branch # prints: shastings-dev
hg merge --tool internal:other coworker-dev
hg commit -m "merge coworker-dev" --subrepos
hg push
は次のhg pushメッセージを出力します。
abort: push creates new remote head 945a60694252 on branch 'shastings-dev'! (in subrepo sub-a)
編集 - 私はここで質問を壊して答えを出しています。残りの質問は、すべての詳細に本当に興味がある人のために、そのままにしておきます。
解決策: マージが必要なサブレポごとに、ディレクトリをサブレポに変更し、次の手順に従います。
hg update --clean shastings-dev
hg merge --tool internal:other coworker-dev
hg commit -m "merge coworker-dev"
hg push
（私はこれをサブレポsub-aとのために行いsub-bました。sub-c私はちょうどそれが先頭にあることを確認するために走っhg update correct_branch_nameたからです。）
次に、各サブレポが適切に更新されたら、含まれているレポに戻ります。
hg commit -m "commit .hgsubstate after merging in subrepos"
hg push
この経験の結果として、私は新しいルールを採用するつもりです：
サブリポジトリに問題がある場合は、常に個々のサブリポジトリでコマンドを再試行してください。
私を混乱させたのは、hg update --cleanすべてのサブリポジトリを切り替えたが、実際には更新しなかったことです。サブリポジトリのヘッドは、 で示されているブランチとは別のブランチに属していましたhg branch。その結果、@zerkms のコメントは正しかった: サブレポは実際にはヘッドになく、マージは実際に新しいヘッドを作成していた.
つまり、hg idメインリポジトリが先頭にあることを示していても、サブリポジトリが適切に更新され、それぞれの先頭にあることを意味するわけではありません。サブリポジトリを個別にチェックして、実際の状態を把握してください。
編集 - 元の質問の残りは以下です。私が最初に考えたのは、リポジトリのローカル コピーが何らかの形でスクランブルされているということでした。そのため、リポジトリの完全に新しいコピーを複製し、hg pull新しいものがないことを確認して、マージ/コミット/プッシュを再試行しました。同じ問題。
サブレポでマージ/コミット/プッシュを実行してから、メインレポでコミットを実行し( update .hgsubstate)、メインレポでマージ/コミット/プッシュを実行しようとしました。喜びはありません。
Windows で TortoiseHg を使用してレポをクローンし、ブランチに更新してからshastings-dev、マージ/コミット/プッシュしようとしました。同じ問題。
だから今私の質問：
なぜ新しい頭が作られるのですか？私は何か間違ったことをしていますか、ブランチに何か問題がありますか、それともこれは予期された動作ですか?
私は何をすべきか？この複数のヘッドの問題を解決できますか、または でプッシュして
-fから、2 つのヘッドのうち古い方を で閉じる必要がありhg commit --close-branchますか?を使用すると、どのような悪いことが起こる可能性があります
hg push -fか? 私の個人的なルールは、「あなたが Mercurial の専門家でない限り、これを行うべきではない」ということです。私は Mercurial の専門家ではありません。（つまり、私の実際の個人的なルールは「決して使用しないhg push -f」です。）
ちなみに、私は同僚が作業しているファイルには取り組んでいません。現時点では、 との違いはわずかであり、同じ名前の最新のブランチを動作させることができる限り、coworker-devブランチ のすべての履歴を完全に失うことを厭いません。shastings-dev(変更を失った場合は、変更されたファイルをもう一度コピーします。Mercurial が再び期待どおりに動作することを望んでいます。)
編集：上記を行うとき、私はブランチヘッドにいます。
$ hg heads
changeset: 1515:803ea844dc8a
branch: coworker2-dev
tag: tip
user: coworker2
date: Tue Oct 08 17:33:31 2013 -0700
files: .hgsubstate
description:
Fixed some stuff in the foo bar.
changeset: 1513:1e76e6a43d83
branch: coworker-dev
parent: 1509:5e5392aded0a
user: coworker@place_where_i_work.com
date: Tue Oct 08 16:44:04 2013 -0700
files: foo.java bar.java baz.java quux.java
description:
Added more support to the foo bar for release.
changeset: 1422:8705d62db8f2
branch: shastings-dev
user: shastings@place_where_i_work.com
date: Wed Oct 02 21:08:39 2013 -0700
files: .hgsubstate
description:
Finish adding files
...many others not copied here...
$ hg id
8705d62db8f2 (shastings-dev)
$ hg update --clean shastings-dev
resolving manifests
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg id
8705d62db8f2 (shastings-dev)
$ hg merge --tool internal:other coworker-dev
...much output not copied here...
$ hg commit -m "merge coworker-dev" --subrepos
...much output not copied here...
$ hg push
pushing to https://path/to/repo/dir/main-repo
pushing subrepo sub-a to https://path/to/repo/dir/sub-a
searching for changes
new remote heads on branch 'shastings-dev'
new remote head 85d8faada6c4
new remote head 90ce145db695
abort: push creates new remote head 85d8faada6c4 on branch 'shastings-dev'! (in subrepo sub-a)
(you should pull and merge or use push -f to force)
前述したように、問題が発生したときは、すべてを再クローン化しました。したがって、ステータスはクリーンです。変更されたファイルはありません。
また、別のブランチがあり、他のブランチで上記のシーケンスを試しました。説明したとおりにまた起こりました。coworker-devしたがって、何か問題がある場合は、自分のブランチではなく、ブランチで間違っているに違いないと考えています。