Hg: Jak zrobić rebase, takie jak rebase gita

W Git mogę to zrobić:

1. Rozpocznij pracę nad nową funkcją:
$ git co -b newfeature-123 # (lokalny oddział rozwoju funkcji)
zrobić kilka zmian (M, N, O)

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

2. Wyciągnij nowe zmiany z głównego urządzenia nadrzędnego:
$ git pull
(wzorzec zaktualizowany o ff-commits)

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

3. Wyłącz system główny, aby moja nowa funkcja 
można opracować w oparciu o najnowsze zmiany upstream:
(od newfeature-123)
$ git rebase master

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

Chcę wiedzieć, jak zrobić to samo w Mercurial, i szukałem odpowiedzi w Internecie, ale najlepsze, co mogłem znaleźć, to: git rebase - czy mogę to zrobić

Ten link zawiera 2 przykłady:
1. Przyznaję, że to: (zastępując poprawki z przykładu tymi z mojego własnego przykładu)

hg w górę -CF  
gałąź hg -f nowa funkcja-123  
przeszczep hg -a -b nowa cecha-123 

nie jest tak źle, z tym wyjątkiem, że pozostawia MNO w fazie wstępnej jako nierozłożoną głowę i tworzy 3 nowe zatwierdzenia M ', N', O ', które reprezentują ich rozgałęzienie poza zaktualizowaną linią główną.

Zasadniczo problem polega na tym, że kończę na tym:

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

nie jest to dobre, ponieważ pozostawia po sobie lokalne, niechciane zatwierdzenia, które należy porzucić.

2. Inną opcją z tego samego linku jest

hg qimport -r M: O
hg qpop -a
hg w górę F
oddział hg newfeature-123
hg qpush -a
hg qdel -r qbase: qtip

a to daje pożądany wykres:

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

ale te polecenia (wszystkie 6!) wydają się o wiele bardziej skomplikowane niż

$ git rebase master

Chcę wiedzieć, czy jest to jedyny odpowiednik w Hg, czy jest dostępny inny prosty sposób, taki jak Git.

VonC ma odpowiedź, której szukasz - rozszerzenie Rebase. Warto jednak poświęcić sekundę lub dwie na zastanowienie się, dlaczego ani mq, ani rebase nie są domyślnie włączone w mercurial: ponieważ mercurial polega na nieusuwalnych zestawach zmian. Kiedy pracuję w sposób, który opisujesz, czyli prawie codziennie, oto wzór, który biorę:

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

i to naprawdę wszystko, co jest konieczne. Skończyłem z klonem newfeature-123, który z łatwością mogę zepchnąć z powrotem do głównej linii, gdy jestem z niego zadowolony. Najważniejsze jednak, że nigdy nie zmieniłem historii . Ktoś może spojrzeć na moje zestawy i zobaczyć, na czym były pierwotnie zakodowane i jak zareagowałem na zmiany w głównej linii podczas mojej pracy. Nie wszyscy myślą, że to ma wartość, ale jestem głęboko przekonany, że zadaniem kontroli źródła jest pokazanie nam nie tego, co chcielibyśmy, aby się wydarzyło, ale co się faktycznie wydarzyło - każda martwa chwila i każdy refaktor powinien pozostawić nieusuwalny ślad, a następnie i inne techniki edycji historii to ukrywają.

Teraz idź i wybierz odpowiedź VonC, kiedy odkładam mydło. :)

Być może szukasz Rebase Extension . (wdrożony w ramach SummerOfCode 2008 )

W takich przypadkach przydatne może być „odłączenie” lokalnych zmian, zsynchronizowanie repozytorium z głównym nurtem, a następnie dodanie prywatnych zmian do nowych zdalnych zmian. Ta operacja nazywa się rebase.

Dostawać od :

do:

Jak skomentowano poniżej przez steprobe :

W przypadku, gdy nie wprowadzasz zmian i masz dwie gałęzie w swoim repozytorium, możesz zrobić ( używająckeepbranches ):

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

( --keepbranches: Dziedzicz oryginalną nazwę oddziału).

Mojca wspomina:

Lubię używać hg rebase --source {L1's-sha} --dest {R2's-sha}, ale nie wiedziałem, że mogę dodać --keepbranchesna końcu.

Jak pokazano poniżej przez Jonathana Blackburn :

 hg rebase -d default --keepbranches

Zakładając, że masz nowoczesną instalację Hg, możesz po prostu dodać:

[extensions]
rebase = 

do ~ / .hgrc.

Następnie można użyć polecenia hg rebase, hg pull --rebasealbo hg help rebase.

Nie sądzę, aby powyższe odpowiedzi osiągnęły cel PO, którym było utrzymanie jego gałęzi zadań, po prostu opartej na późniejszym punkcie gałęzi nadrzędnej.

Załóżmy, że zaczynam od tego wykresu (wygenerowanego przy użyciu rozszerzenia graphlog. Poważna geekowska miłość do graphlog).

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

Jeśli jestem w gałęzi feature3 i chcę ją wyrenderować przy ponownym zatwierdzeniu, rozumiem, że bym uruchomił hg rebase -d default. Ma to następujący wynik:

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

Misja zrealizowana? Nie wydaje mi się Problem polega na tym, że gdy zatwierdzenia na gałęzi feature3 zostały ponownie oparte na ponownie, gałąź Feature3 została usunięta . Moje commity zostały przeniesione do domyślnego oddziału, czego starałem się przede wszystkim uniknąć.

W Git wynik wyglądałby tak:

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

Zauważ, że gałąź Feature3 nadal istnieje, dwa zatwierdzenia są nadal w gałęzi Feature3 i domyślnie nie są widoczne. Bez zachowania gałęzi zadania nie widzę, jak funkcjonalnie różni się to od scalenia.

AKTUALIZACJA : Odkryłem --keepbranchesflagę obsługiwaną przez hg rebase i cieszę się, że wszystko jest w porządku. Używając hg rebase -d default --keepbranchesdokładnie replikuję zachowanie Git, którego pragnąłem. Kilka pseudonimów później, a ja odpłacam się jak niczyja sprawa.

Ponieważ niektórzy ludzie twierdzą, że uważają, że dobrze jest zachować każdą iterację wszystkiego, zaznaczę, że w przypadku większych projektów typu open source zaakceptowanie zmian połączonych i iteracji rozwoju spowodowałoby niechlujną historię zmian głównej linii i historia zmian jest mniej przydatna do sprawdzania, w jaki sposób dotarła tam obecna wersja.

Działa to dobrze, gdy przesłane zmiany są sprawdzane przez osoby, które ich nie napisały, zanim zostaną zaakceptowane, więc zmiany, które wchodzą w linię główną, są na ogół debugowane i działają. Następnie, gdy cofniesz się do początku linii, zobaczysz wszystkie zmiany, które się z nią wiążą, a nie jakiś punkt w środku rozwoju zmiany, której jest częścią.

Strona współtwórców x265 wyjaśnia, jak ponownie zatwierdzić zestaw zmian, nad którymi pracujesz, aby przygotować je do przesłania do projektu x265. (W tym użycie TortoiseHG do zatwierdzenia niektórych, ale nie wszystkich zmian w pojedynczym pliku, takich jak git gui stage / unstage diff hunk do zatwierdzenia).

Proces polega na zaktualizowaniu hg do wskazówki nadrzędnej, a następnie niezakceptowaniu wszystkich zmian w katalogu roboczym. Odłóż na półkę te, które nie są częścią tego, co chcesz przesłać, a następnie podziel resztę na tyle, ile jest odpowiednich osobnych zatwierdzeń, z ładnymi komunikatami zatwierdzania.

Myślę, że skopiujesz / wkleisz, a następnie edytujesz komunikaty zatwierdzenia z poprzednich iteracji poprawionego zestawu łat. A może możesz przeszczepić swoje stare zatwierdzenia (cherry-pick w języku git), a następnie zmieniać je jeden po drugim, aby otrzymać stare komunikaty zatwierdzeń jako punkt wyjścia do edycji.