Hg：gitのリベースのようなリベースを行う方法

Gitではこれを行うことができます：

1.新しい機能の作業を開始します。
$ git co -b newfeature-123＃（ローカル機能開発ブランチ）
いくつかのコミットを行う（M、N、O）

マスターA --- B --- C
                \
newfeature-123 M --- N --- O

2.アップストリームマスターから新しい変更をプルします。
$ git pull
（ff-commitsで更新されたマスター）

マスターA --- B --- C --- D --- E --- F
                \
newfeature-123 M --- N --- O

3.マスターをリベースして、私の新機能を 
最新の上流の変更に対して開発することができます：
（newfeature-123から）
$ git rebase master

マスターA --- B --- C --- D --- E --- F
                            \
newfeature-123 M --- N --- O

Mercurialで同じことをする方法を知りたいのですが、Webを調べて答えを探しましたが、私が見つけた最善の方法はgit rebaseです。

そのリンクは2つの例を提供します：
1.私はこれを認めます：（例のリビジョンを自分の例のリビジョンで置き換えます）

hg up -CF  
hgブランチ-f newfeature-123  
hg移植-a -b newfeature-123 

リベース前のMNOをマージされていないヘッドとして残し、更新されたメインラインから分岐することを表す3つの新しいコミットM '、N'、O 'を作成することを除いて、それほど悪くはありません。

基本的に問題は私がこれで終わることです：

マスターA --- B --- C --- D --- E --- F
                \ \
newfeature-123 \ M '--- N' --- O '
                  \
newfeature-123 M --- N --- O

削除する必要があるローカルの不要なコミットが残るため、これは適切ではありません。

2. 同じリンクからの他のオプションは

hg qimport -r M：O
hg qpop -a
hg up F
hgブランチnewfeature-123
hg qpush -a
hg qdel -r qbase：qtip

そしてこれは望ましいグラフになります：

マスターA --- B --- C --- D --- E --- F
                            \
newfeature-123 M --- N --- O

しかし、これらのコマンド（6つすべて！）は、

$ git rebase master

これがHgで唯一の同等のものか、Gitのような単純な他の方法が利用できるかどうかを知りたいです。

VonCはあなたが探している答えであるRebase Extension を持っています。ただし、me​​rcurialではデフォルトでmqもrebaseも有効になっていない理由について少し考えてみる価値があります。私があなたが説明している方法で作業するとき、これはほぼ毎日ですが、これが私が取るパターンです：

1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)

master A---B---C
                \
newfeature-123   M---N---O

2. Pull new changes from upstream mainline:
$ hg pull

master A---B---C---D---E---F
                \
newfeature-123   M---N---O

3. merge master into my clone so that my new feature 
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F

master A---B---C---D---E---F
                \           \
newfeature-123   M---N---O---P

必要なのはそれだけです。最終的にはnewfeature-123クローンになり、満足したらメインラインに簡単に戻すことができます。最も重要なのは、しかし、私は歴史を変えたことはありません。誰かが私のcsetを見て、それらが元々何に対してコーディングされていたか、そして作業中のメインラインの変更にどのように反応したかを見ることができます。誰もがそれが価値があると思うわけではありませんが、私たちが望んでいたことが起こったのではなく、実際に起こったことを示すのはソース管理の仕事であると私は確信しています-すべての行き止まりとすべてのリファクタリングは消えない痕跡を残し、リベースする必要がありますそして他の履歴編集技術はそれを隠します。

soapboxを片付けている間、VonCの答えを選んでください。:)

Rebase Extensionを探しているかもしれません。（SummerOfCode 2008の一部として実装）

このような場合、ローカルの変更を「切り離して」、リポジトリをメインストリームと同期させてから、新しいリモートの変更の上にプライベートな変更を追加すると便利です。この操作はリベースと呼ばれます。

からの行き方：

に：

以下のコメントでsteprobe：

変更をプルしておらず、リポジトリに2つのブランチがある場合、次のようにできます（を使用keepbranches）。

hg up newfeature-123 
hg rebase -d master --keepbranches

（--keepbranches：元のブランチ名を継承します。）

Mojcaは次のように述べています。

私はを使うのhg rebase --source {L1's-sha} --dest {R2's-sha}が好きですが--keepbranches、最後に追加できることを知りませんでした。

以下に例示することにより、ジョナサン・ブラックバーン：

 hg rebase -d default --keepbranches

最新のHgインストールがあると仮定すると、単純に以下を追加できます。

[extensions]
rebase = 

〜/ .hgrcに。

その後、コマンドを使用することができhg rebase、hg pull --rebaseまたはhg help rebase。

上記の答えがOPの目標（タスクブランチを維持し、親ブランチの後のポイントに基づいてリベースする）を達成したとは思いません。

このグラフ（graphlog拡張を使用して生成されたものです。graphlogに対するマニアックな愛情）から始めましょう。

@  9a4c0eb66429 Feature 3 commit 2 tip feature3
|
| o  af630ccb4a80 default againagainagain  
| |
o |  98bdde5d2185 Feature 3 branch commit 1  feature3
|/
o  e9f850ac41da foo   

私がfeature3ブランチを使用していて、againagagainコミットからそれをリベースしたい場合は、実行すると理解していますhg rebase -d default。これにより、次の結果が得られます。

@  89dada24591e Feature 3 commit 2 tip 
|
o  77dcce88786d Feature 3 branch commit 1  
|
o  af630ccb4a80 default againagainagain  
|
o  e9f850ac41da foo  

任務完了？そうは思いません。問題は、feature3ブランチでのコミットが再び再びベースにされたときに、feature3ブランチが削除されたことです。私のコミットはデフォルトのブランチに移動されました。これは私が最初に回避しようとしていたものです。

Gitでは、結果は次のようになります。

@  9a4c0eb66429 Feature 3 commit 2 tip
|
o  98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o  af630ccb4a80 default againagainagain
|
o  e9f850ac41da foo

feature3ブランチがまだ存在し、2つのコミットがまだfeature3ブランチにあり、デフォルトでは表示されないことに注意してください。タスクブランチを保持しないと、これがマージと機能的にどのように異なるのかわかりません。

更新：私は発見した--keepbranches hg rebaseでサポートさフラグ。すべてがokey-dokeyであることを報告させていただきます。を使用してhg rebase -d default --keepbranches、私が切望したGitの動作を正確に再現します。後でいくつかのエイリアスがあり、私は誰の仕事のようにリベースしています。

一部の人々はすべてのイテレーションをすべて維持するのが良いと思っていると言ってきたので、大規模なオープンソースプロジェクトの場合、マージと開発のイテレーションでいっぱいの変更を受け入れると、面倒なメインラインの改訂履歴が作成され、現在のバージョンがどのようにそこに到達したかを確認するのにあまり役に立たない改訂履歴。

これは、送信された変更が受け入れられないうちに、それらを記述していない人々によってレビューされたときにうまく機能するため、メインラインに送られる変更は、通常、デバッグされて機能します。次に、ラインの原点に戻ると、それに伴う変更のすべてが表示されます。変更が発生している途中の途中ではありません。

x265の貢献者のページには、説明の提出のためにそれらを準備するために、あなたが取り組んでいる一連の変更を再コミットする方法 x265プロジェクトへ。（Git guiのステージ用/ステージ解除用の差分ハンクのコミットのように、TortoiseHGを使用して個々のファイルのすべてではなく一部の変更をコミットすることを含みます）。

このプロセスでは、hgを上流のヒントに更新し、すべての変更を作業ディレクトリでコミットせずに取得します。あなたが提出したいものの一部ではないものを棚上げし、素敵なコミットメッセージで適切な数の個別のコミットに残りを分割してください。

私はあなたが修正しているパッチセットの以前のイテレーションからのコミットメッセージをコピー/貼り付けしてから編集すると思います。または、古いコミット（git言語でのチェリーピック）を移植し、1つずつ修正して、古いコミットメッセージを編集の開始点として取得することもできます。