Hg: Як зробити ребауз, як ребат git

У Git я можу це зробити:

1. Почніть працювати над новою функцією:
$ git co -b newfeature-123 # (галузь розвитку місцевих функцій)
зробіть кілька комітів (M, N, O)

майстер A --- B --- C
                \
новахарактеристика-123 M --- N --- O

2. Витягніть нові зміни з головного потоку:
$ git тягнути
(master оновлено ff-commits)

майстер A --- B --- C --- D --- E --- F
                \
новахарактеристика-123 M --- N --- O

3. Перезавантажте майстер, щоб отримати мою нову функцію 
може бути розроблено на основі останніх змін вище за течією:
(з нової особливості-123)
$ git master rebase

майстер A --- B --- C --- D --- E --- F
                            \
новахарактеристика-123 M --- N --- O

Я хочу знати, як зробити те ж саме в Mercurial, і я шукав відповідь в Інтернеті, але найкраще, що я міг знайти, це: git rebase - може Hg зробити це

Це посилання містить 2 приклади:
1. Я визнаю, що це: (замінюючи редакції з прикладу на ті, що є з мого власного прикладу)

hg вгору -CF  
hg гілка -f newfeature-123  
hg трансплантація -a -b новахарактеристика-123 

Не надто погано, за винятком того, що він залишає позаду попередньої рестарації MNO у вигляді нерозподіленої головки та створює 3 нові коміти M ', N', O ', які представляють їх, відгалужуючи оновлений магістраль.

В основному проблема полягає в тому, що я закінчую це:

майстер A --- B --- C --- D --- E --- F
                \ \
новафункція-123 \ M '--- N' --- O "
                  \
новахарактеристика-123 M --- N --- O

це не добре, оскільки воно залишає після себе місцеві, небажані вчинки, які слід відмовитися.

2. Інший варіант із того ж посилання є

hg qimport -r M: O
hg qpop -a
hg вгору F
hg гілка newfeature-123
hg qpush -a
hg qdel -r qbase: qtip

і це призводить до отримання потрібного графіка:

майстер A --- B --- C --- D --- E --- F
                            \
новахарактеристика-123 M --- N --- O

але ці команди (всі 6!) здаються набагато складнішими, ніж

$ git master rebase

Я хочу знати, чи це єдиний еквівалент Hg, чи є інший доступний спосіб, такий як Git.

VonC має відповідь, яку ви шукаєте , розширення Rebase. Однак варто витратити секунду-дві на роздуми над тим, чому ні mq, ні перезавантаження не включені за замовчуванням у mercurial: тому що mercurial - це все для незмінних наборів змін. Коли я працюю так, як ви описуєте, що майже щодня, ось такий шаблон:

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

і це дійсно все, що потрібно. Я закінчую новим клоном-123, який я можу легко відштовхуватися від магістралі, коли я задоволений цим. Найголовніше, однак, я ніколи не змінював історію . Хтось може подивитися на мої каси і побачити, на чому вони були спочатку закодовані, і як я відреагував на зміни основної лінії протягом своєї роботи. Не всі вважають, що це має цінність, але я твердо вірю, що завдання контролю над джерелами - це показати нам не те, що ми хотіли, а траплялося, а те, що насправді сталося - кожен декадент і кожен рефактор повинен залишати незгладимий слід і відновлювати та інші методи редагування історії приховують це.

Тепер переходьте до відповіді VonC, коли я відкладаю свою мильну скриньку. :)

Ви можете шукати розширення Rebase . (реалізовано в рамках SummerOfCode 2008 )

У цих випадках може бути корисно "від'єднати" локальні зміни, синхронізувати сховище з основним потоком і потім додати приватні зміни поверх нових віддалених змін. Ця операція називається rebase.

Отримання :

до:

Як прокоментував нижче по steprobe :

У випадку, коли ви не втягуєте зміни, і у вас є дві гілки в репо, ви можете зробити ( використовуючиkeepbranches ):

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

( --keepbranches: Успадкуйте оригінальну назву гілки.)

Мохка згадує:

Мені подобається використовувати hg rebase --source {L1's-sha} --dest {R2's-sha}, але я не знав, що можу додати --keepbranchesв кінці.

Як показано нижче на Jonathan Blackburn :

 hg rebase -d default --keepbranches

Припускаючи, що у вас є сучасна установка Hg, ви можете просто додати:

[extensions]
rebase = 

до ~ / .hgrc.

Потім ви можете використовувати команди hg rebase, hg pull --rebaseабо hg help rebase.

Я не думаю, що вищевказані відповіді досягають мети ОП, яка полягала в тому, щоб підтримувати свою галузь завдань, щойно відхилилася від наступної точки батьківської гілки.

Скажімо, я починаю з цього графіка (згенерований за допомогою розширення graphlog. Серйозна любов до викладачів).

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

Якщо я перебуваю на гілці особливостей3 і хочу відновити її за межі зобов’язання againagainagain, я розумію, що я би запускався 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 були перезавантажені на againagainagain, гілка feature3 була видалена . Мої комітети були переміщені до гілки за замовчуванням, чого я намагався уникати в першу чергу.

У Git результат виглядатиме так:

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

Зауважте, що гілка особливості3 все ще існує, два коміти все ще знаходяться на гілці функцій3 і не видно за замовчуванням. Не зберігаючи гілки завдань, я не бачу, наскільки це функціонально відрізняється від злиття.

ОНОВЛЕННЯ : Я виявив --keepbranchesпрапор, підтримуваний hg rebase, і я радий повідомити, що все є okey-dokey. Використовуючи hg rebase -d default --keepbranches, я точно повторюю поведінку Git, якої я прагнув. Кілька псевдонімів пізніше, і я відмовляюся, як ні в кого справа.

Оскільки деякі люди звучали, кажучи, що вважають, що добре тримати кожну ітерацію всього, я зазначу, що для великих проектів з відкритим кодом прийняття змін, повних об'єднань і ітерація розвитку, призведе до безладної історії перегляду основних напрямків, і зробити це історія редагування менш корисна для того, щоб побачити, як там дійшла поточна версія.

Це добре працює, коли внесені зміни переглядаються людьми, які їх не написали, перш ніж їх прийняти, тому зміни, які дійсно переходять у основну лінію, як правило, налагоджуються та працюють. Потім, коли ви повертаєтеся до початку лінії, ви бачите всі зміни, що пов'язані з нею, а не якийсь момент в середині розвитку зміни, в якій вона входить.

Сторінка дописувачів x265 пояснює, як повторно здійснити набір змін, над якими ви працюєте, щоб підготувати їх до подання в проект x265. (У тому числі використання TortoiseHG для внесення деяких, але не всіх змін в окремому файлі, наприклад, етап / нестабільність git gui diff hunk для фіксації).

Процес полягає в тому, щоб оновити hg до кінця вгору, а потім отримати всі зміни, що не відбулися, у робочому каталозі. Зберігайте будь-які, які не є частиною того, що ви хочете надіслати, а потім розбийте решту на ті самі необхідні кількості окремих комісій із приємними повідомленнями про фіксацію.

Я думаю, ви скопіювали / вставили, а потім відредагували повідомлення про фіксацію попередніх ітерацій патчету, які ви переглядаєте. Або, можливо, ви зможете прищепити свої старі комісії (вишня вибору мовою git), а потім поправити їх по черзі, щоб ваші старі повідомлення про фіксацію стали початковим пунктом для редагування.