これは通常のワークフローではありませんか？なぜ--new-branchフラグが必要ですか？
[default] $ hg branch foo
[foo] $ [... some commits ...]
[foo] $ hg update default
[default] $ hg merge foo
[default] $ hg commit -m "merged foo"
[default] $ hg push
abort: push creates new remote branches: foo!
(use 'hg push --new-branch' to create new remote branches)
ブランチング→マージ→プッシュを行う理想的な方法は何ですか？
水銀の哲学は、リポジトリの他のユーザーにとってより困難にするようなことを押しつけるべきではないということです。この質問に関連するのは、複数のヘッドが他の開発者にとっては、変更をマージする必要があるため、難しくなってしまうことです。したがって、デフォルトでは、新しいヘッドのプッシュはサーバーによって拒否されます。 -fオプションを使用して新しいヘッドを押すことができました。
しかし、新しい名前付きブランチをプッシュする場合は、概念的には同じブランチ上で新しいヘッドをプッシュすることとは全く異なります。多くのワークフロー（私を含む）は、別々の名前付きブランチ上で各タスクを実行します。 --new-branchオプションを使用すると、既存のブランチ上の新しいヘッドを拒否しながら、新しいブランチを押し上げることができます。新しいブランチが（マージのために）新しいヘッドを作成しなくても必要なので、（あなたが見たように）これも異なっています。
私の個人的な感想は、新しいブランチはデフォルトで許可されるべきですが、水銀の開発者はそうでないと好みます。
これは1回限りのものです。最初に（新しい）ブランチを押すときに--new-branchを使うだけです。それは正常です。
その他のプッシュはすべて、hg push、--new-branchフラグのままです。
プッシュ前に名前付きブランチを削除する '--close-branch'を実行するとどうなりますか？私はこの中止をしてはならないのですか？それは今私に起こったばかりです。 –
これは、ブランチの用途によって異なります。
独自のリポジトリクローンで内部的に使用されていますが、他のリポジトリから切り離された機能で開発する限り、ブランチに変更をコミットすることが適切です。
あなたが競合があなたをコミット解決、そして、あなたはそれらの変更を更新する必要があり、デフォルトのブランチ
上の変更を行っていることが他の人々の努力に追跡するためにいくつかの仕事を投資する必要があります終えた後、部。 デフォルトに切り替え、変更をマージして、デフォルトのブランチにフィーチャーを設定します。今すぐあなたの支店を閉じて、物事をコミットし、それを押すことができます！
私は2年間* hgを使用していますが、あなたが何を意味するのか分かりません。あなたはその質問に答えていますか？ –
内部的には、新しいブランチが新しいヘッドであり、hgが-f（強制）オプションを指定して新しいヘッドを送信するために失敗するためです。 –
あなたが理解しているギャップは、fooをデフォルトにマージしたにもかかわらず、Mercurial（gitと違って）では、まだ変更不可能なブランチ属性が 'foo'のチェンジセットを送信している可能性があります。 gitでは、fooという名前はそれらのコマンドでローカルシステムをエスケープすることは決してありませんが、Mercurialでは、その動作をしたい場合は、名前のついた枝ではなくブックマークを使います。 –