Hg: Cara melakukan rebase seperti rebit git

Di Git saya bisa melakukan ini:

1. Mulai bekerja pada fitur baru:
$ git co -b newfeature-123 # (cabang pengembangan fitur lokal)
lakukan beberapa komit (M, N, O)

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

2. Tarik perubahan baru dari master hulu:
$ git pull
(master diperbarui dengan ff-commit)

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

3. Rebase off master sehingga fitur baru saya 
dapat dikembangkan melawan perubahan hulu terbaru:
(dari newfeature-123)
$ git rebase master

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

Saya ingin tahu bagaimana melakukan hal yang sama di Mercurial, dan saya telah menjelajahi web untuk mendapatkan jawaban, tetapi yang terbaik yang bisa saya temukan adalah: git rebase - dapat hg melakukan itu

Tautan itu memberikan 2 contoh:
1. Saya akui ini: (mengganti revisi dari contoh dengan yang dari contoh saya sendiri)

hg up -CF  
cabang hg -f fitur baru-123  
hg transplantasi -a -b newfeature-123 

tidak terlalu buruk, kecuali bahwa ia meninggalkan MNO pra-rebase sebagai kepala yang tidak bermutasi dan menciptakan 3 komit baru M ', N', O 'yang mewakili mereka bercabang dari arus utama yang diperbarui.

Pada dasarnya masalahnya adalah saya berakhir dengan ini:

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

ini tidak baik karena meninggalkan komitmen lokal yang tidak diinginkan yang harus dijatuhkan.

2. Opsi lain dari tautan yang sama adalah

hg qimport -r M: O
hg qpop -a
hg up F
cabang hg newfeature-123
hg qpush -a
hg qdel -r qbase: qtip

dan ini menghasilkan grafik yang diinginkan:

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

tetapi perintah ini (semuanya 6)! Tampaknya jauh lebih rumit daripada

$ git rebase master

Saya ingin tahu apakah ini satu-satunya yang setara dalam Hg atau jika ada cara lain yang tersedia yang sederhana seperti Git.

VonC memiliki jawaban yang Anda cari , Ekstensi Rebase. Namun demikian, layak menghabiskan satu atau dua detik untuk memikirkan mengapa mq atau rebase tidak diaktifkan secara default di mercurial: karena mercurial adalah semua tentang perubahan yang tidak terhapuskan. Ketika saya bekerja dengan cara yang Anda gambarkan, yang hampir setiap hari, inilah pola yang saya ambil:

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

dan hanya itu yang perlu. Saya berakhir dengan klon fitur-123 yang baru. Saya dapat dengan mudah mendorong kembali ke garis utama ketika saya senang dengan itu. Namun yang paling penting, saya tidak pernah mengubah sejarah . Seseorang dapat melihat csets saya dan melihat apa yang semula dikodekan terhadapnya dan bagaimana saya bereaksi terhadap perubahan pada arus utama sepanjang pekerjaan saya. Tidak semua orang berpikir memiliki nilai, tapi saya sangat percaya bahwa tugas pengendalian sumber bukan untuk menunjukkan kepada kita apa yang kita harapkan terjadi, tetapi apa yang sebenarnya terjadi - setiap deadend dan setiap refactor harus meninggalkan jejak yang tidak terhapuskan, dan rebasing dan teknik penyuntingan riwayat lainnya menyembunyikannya.

Sekarang pilih jawaban VonC sementara saya menyimpan kotak sabun saya. :)

Anda mungkin mencari Ekstensi Rebase . (diimplementasikan sebagai bagian dari SummerOfCode 2008 )

Dalam kasus-kasus tersebut, akan berguna untuk "melepaskan" perubahan lokal, menyinkronkan repositori dengan arus utama dan kemudian menambahkan perubahan pribadi di atas perubahan jarak jauh yang baru. Operasi ini disebut rebase.

Dapatkan dari :

untuk:

Seperti yang dikomentari di bawah ini oleh steprobe :

Dalam kasus di mana Anda tidak menarik perubahan, dan Anda memiliki dua cabang di repo Anda, Anda dapat melakukan ( menggunakankeepbranches ):

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

( --keepbranches: Mewarisi nama cabang asli.)

Mojca menyebutkan:

Saya suka menggunakan hg rebase --source {L1's-sha} --dest {R2's-sha}, tetapi saya tidak tahu saya bisa menambahkan --keepbranchesdi akhir.

Seperti diilustrasikan di bawah ini oleh Jonathan Blackburn :

 hg rebase -d default --keepbranches

Dengan asumsi Anda memiliki instalasi Hg modern, Anda dapat menambahkan:

[extensions]
rebase = 

ke ~ / .hgrc.

Kemudian Anda dapat menggunakan perintah hg rebase, hg pull --rebaseatau hg help rebase.

Saya tidak berpikir jawaban di atas mencapai tujuan OP, yaitu untuk mempertahankan cabang tugasnya, baru saja diubah terhadap poin selanjutnya pada cabang induk.

Katakanlah saya mulai dengan grafik ini (dihasilkan menggunakan ekstensi graphlog. Geek cinta serius untuk graphlog).

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

Jika saya berada di cabang feature3 dan ingin mengembalikannya dari komitmen lagi lagi, saya mengerti bahwa saya akan lari hg rebase -d default. Ini memiliki hasil sebagai berikut:

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

Misi selesai? Saya kira tidak. Masalahnya adalah ketika komit pada cabang feature3 direstrukturisasi kembali lagi, cabang fitur3 dihapus . Komit saya telah dipindahkan ke cabang default, yang merupakan hal yang saya coba hindari sejak awal.

Di Git, hasilnya akan terlihat seperti ini:

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

Perhatikan bahwa cabang feature3 masih ada, kedua komit masih pada cabang feature3, dan tidak terlihat secara default. Tanpa mempertahankan cabang tugas, saya tidak melihat bagaimana ini secara fungsional berbeda dari gabungan.

UPDATE : Saya menemukan --keepbranchesbendera yang didukung oleh hg rebase, dan saya senang melaporkan semuanya okey-dokey. Dengan menggunakan hg rebase -d default --keepbranches, saya mereplikasi perilaku Git yang saya inginkan. Beberapa alias kemudian dan saya rebasing seperti urusan siapa pun.

Karena beberapa orang telah menimpali dengan mengatakan mereka pikir itu baik untuk menjaga setiap iterasi dari segalanya, saya akan menunjukkan bahwa untuk proyek open-source yang lebih besar, menerima perubahan yang penuh dengan penggabungan dan pengembangan iterasi akan membuat sejarah revisi garis utama berantakan, dan membuat riwayat revisi kurang bermanfaat untuk melihat bagaimana versi saat ini sampai di sana.

Ini berfungsi dengan baik ketika perubahan yang diajukan ditinjau oleh orang-orang yang tidak menulisnya, sebelum diterima, sehingga perubahan yang masuk ke jalur utama umumnya didebug dan berfungsi. Lalu ketika Anda mundur ke asal suatu baris, Anda melihat semua perubahan yang menyertainya, bukan titik di tengah pengembangan perubahan itu bagian dari.

The kontributor x265 Halaman menjelaskan bagaimana untuk kembali melakukan serangkaian perubahan yang sedang Anda kerjakan, untuk membuat mereka siap untuk diserahkan ke proyek x265. (Termasuk penggunaan TortoiseHG untuk mengkomit beberapa tetapi tidak semua perubahan dalam file individual, seperti stage git gui / unstage diff hunk untuk commit).

Prosesnya adalah untuk mendapatkan hg diperbarui ke ujung hulu, dan kemudian dapatkan semua perubahan Anda tidak dikomit di direktori kerja. Singkirkan apa pun yang bukan bagian dari apa yang ingin Anda kirim, kemudian bagi sisanya menjadi banyak komit terpisah yang sesuai, dengan pesan komit yang bagus.

Saya kira Anda akan menyalin / menempel dan kemudian mengedit pesan komit dari iterasi sebelumnya dari patchset yang sedang Anda revisi. Atau mungkin Anda bisa mencangkokkan komitmen lama Anda (pilih-ceri dalam bahasa git), dan kemudian ubah satu per satu, untuk mendapatkan pesan komit lama Anda sebagai titik awal untuk mengedit.