Mercurial przenosi się do nowej gałęzi

124

Mam wiele zmian, które wprowadziłem do mojego lokalnego repozytorium, ale nie zostały one jeszcze wprowadzone. Ponieważ funkcja zajmuje więcej czasu niż oczekiwano, chcę zamienić te zmiany na nazwaną gałąź przed naciśnięciem. W jaki sposób mogę to zrobić?

Casebash
źródło

Odpowiedzi:

153

Jak zasugerował Mark, MqExtension jest jednym z rozwiązań Twojego problemu. IMHO prostszym przepływem pracy jest użycie rozszerzenia rebase . Załóżmy, że masz taką historię:

@  changeset:   2:81b92083cb1d
|  tag:         tip
|  summary:     my new feature: edit file a
|
o  changeset:   1:8bdc4508ac7b
|  summary:     my new feature: add file b
|
o  changeset:   0:d554afd54164
   summary:     initial

Oznacza to, że wersja 0jest podstawą, na której zacząłeś pracować nad swoim elementem. 1-2Powiedzmy, że teraz chcesz mieć poprawki w nazwanej gałęzi my-feature. Zaktualizuj do wersji 0i utwórz tę gałąź:

$ hg up 0
$ hg branch my-feature
$ hg ci -m "start new branch my-feature"

Historia wygląda teraz tak:

@  changeset:   3:b5939750b911
|  branch:      my-feature
|  tag:         tip
|  parent:      0:d554afd54164
|  summary:     start new branch my-feature
|
| o  changeset:   2:81b92083cb1d
| |  summary:     my new feature: edit file a
| |
| o  changeset:   1:8bdc4508ac7b
|/   summary:     my new feature: add file b
|
o  changeset:   0:d554afd54164
   summary:     initial

Użyj rebasepolecenia, aby przenieść wersje 1-2do wersji 3:

$ hg rebase -s 1 -d 3

Daje to następujący wykres:

@  changeset:   3:88a90f9bbde7
|  branch:      my-feature
|  tag:         tip
|  summary:     my new feature: edit file a
|
o  changeset:   2:38f5adf2cf4b
|  branch:      my-feature
|  summary:     my new feature: add file b
|
o  changeset:   1:b5939750b911
|  branch:      my-feature
|  summary:     start new branch my-feature
|
o  changeset:   0:d554afd54164
   summary:     initial

To wszystko… jak wspomniano w komentarzach do odpowiedzi Marka, poruszanie się po już wprowadzonych zestawach zmian jest ogólnie złym pomysłem, chyba że pracujesz w małym zespole, w którym możesz komunikować się i wymuszać manipulowanie historią.

Oben Sonne
źródło
4
IMHO Wadą tego rozwiązania jest to, że wprowadza ono fałszywe zatwierdzenie "start nowej gałęzi moja-funkcja" (tj. Takie, które nie zmienia żadnych plików).
sschuberth
9
@sschuberth: Myślę, że wyraźne wyrażanie się tutaj jest dobrą rzeczą. Jeśli dodatkowy zestaw zmian jest dla ciebie problemem, połącz go z następnym (np. Używając foldpolecenia wbudowanego teraz rozszerzenia histedit ).
Oben Sonne
6
@AmirRachum: hg log -G( GraphlogExtension ). Usunąłem ręcznie niektóre linie, ale mógł też zostać wyrenderowany całkowicie automatycznie przy użyciu niestandardowych stylów dziennika .
Oben Sonne
2
Włącz rozszerzenie rebase : mercurial.selenic.com/wiki/RebaseExtension#Configuration
56ka
1
@sschuberth Zgadzam się. Moim obejściem jest przeniesienie twoich nie-fikcyjnych zatwierdzeń do elementu nadrzędnego fikcyjnego zatwierdzenia za pomocą flagi --keepbranches, a następnie hg usunięcie fikcyjnego zatwierdzenia. Zmiana nazwy oddziału to dużo pracy, ale czasami Mercurial jest taki głupi.
weberc2
30

Możesz użyć MqExtension . Powiedzmy, że zestawy zmian do przeniesienia to wersje 1-3:

hg qimport -r 1:3    # convert revisions to patches
hg qpop -a           # remove all them from history
hg branch new        # start a new branch
hg qpush -a          # push them all back into history
hg qfin -a           # finalize the patches
Mark Tolonen
źródło
Chcę zaimportować 63:64 i 66:68. Otrzymuję wersję 65, która nie jest rodzicem 64
Casebash,
Co chcesz zrobić z 65? Mq może konwertować tylko kolejne zestawy zmian z głowy. Przekształca zwykle niezmienne zestawy zmian w zmienne łaty, które można edytować. Zmienia to skróty (dotyczy wszystkich elementów podrzędnych), więc nie można pominąć.
Mark Tolonen,
Mam kilka zmian (w tym 65), które wprowadziłem na głównej gałęzi i pchnąłem
Casebash
1
Nie edytuj przekazanych zestawów zmian. Mq zmienia skróty, więc będą one faktycznie nowymi zestawami zmian. Tylko historia zmian, która nie została przekazana.
Mark Tolonen,
Jeśli już pchnąłeś 65, to zdecydowanie nie powinieneś wykonywać ruchu 63 i 64, a poprzestać na ruchu 66:68 (znowu, tylko jeśli ich nie przepchnąłeś).
Matt
9

Wolę rozwiązanie łatki opisane tutaj przez Marka Tolonena

Co ja mam:

hg log -G

#default branch
@  changeset:   3:cb292fcdbde1
|
o  changeset:   2:e746dceba503
|
o  changeset:   1:2d50c7ab6b8f
|
o  changeset:   0:c22be856358b

Czego chcę:

  @  changeset:   3:0e85ae268e35
  |  branch:      feature/my_feature
  |
  o  changeset:   2:1450cb9ec349
  |  branch:      feature/my_feature
  |
  o  changeset:   1:7b9836f25f28
  |  branch:      feature/my_feature
  |
 /
|
o  changeset:   0:c22be856358b

polecenia mercurials:

hg export -o feature.diff 1 2 3
hg update 0
hg branch feature/my_feature
hg import feature.diff

Oto stan mojego lokalnego repozytorium

@  changeset:   6:0e85ae268e35
|  branch:      feature/my_feature
|
o  changeset:   5:1450cb9ec349
|  branch:      feature/my_feature
|
o  changeset:   4:7b9836f25f28
|  branch:      feature/my_feature
|
| o  changeset:   3:cb292fcdbde1
| |
| o  changeset:   2:e746dceba503
| |
| o  changeset:   1:2d50c7ab6b8f
|/
|
o  changeset:   0:c22be856358b

Teraz muszę usunąć wersje 1, 2 i 3 z mojej domyślnej gałęzi. Możesz to zrobić za pomocą polecenia strip z rozszerzenia mq. hg stripusuwa zestaw zmian i wszystkie jego elementy potomne z repozytorium.

Włącz rozszerzenie, dodając następujące wiersze do pliku konfiguracyjnego (.hgrc lub Mercurial.ini):

vim ~/.hgrc i dodaj :

[extensions]
mq =

A teraz usuń to repozytorium w wersji 1.

hg strip 1

i oto jesteśmy

@  changeset:   3:0e85ae268e35
|  branch:      feature/my_feature
|
o  changeset:   2:1450cb9ec349
|  branch:      feature/my_feature
|
o  changeset:   1:7b9836f25f28
|  branch:      feature/my_feature
|
o  changeset:   0:c22be856358b

Uwaga: zestawy zmian są różne, ale wersje są takie same

Guillaume Vincent
źródło
5

Dla chętnych do korzystania z GUI

  1. Idź do Tortoise Hg-> File-> Settingsi zaznacz rebase.

wprowadź opis obrazu tutaj

  1. Uruchom ponownie interfejs użytkownika żółwia

  2. Utwórz nową gałąź, w której będziesz przenosić zmiany. Kliknij nazwę aktualnego oddziału -> wybierz Open a new named branch-> wybierz nazwę oddziału.

wprowadź opis obrazu tutaj

  1. Jeśli zmiany, które chcesz przenieść, nie zostały wprowadzone public(np. draft) Przejdź do 5. (Jeśli zmiany zostały już opublikowane, a nie jesteś starszym programistą, powinieneś porozmawiać z kimś starszym (zdobądź kozła ofiarnego), ponieważ możesz coś schrzanić , Nie biorę odpowiedzialności :)).

Idź do View-> Show Console(lub Ctrl+ L), a następnie napisz w konsoli hg phase -f -d 2- gdzie 2 to najniższa wersja, którą będziesz przenosić do nowej gałęzi.

  1. Idź do gałęzi i wersji (powinna to być wersja najwyższa, jeśli przenosisz zmiany do nowej gałęzi utworzonej w kroku 3) Right Mouse->Update

  2. Przejdź do gałęzi i wersji, z której będziesz przenosić zmiany Right Mouse-> Modify History->Rebase

wprowadź opis obrazu tutaj

  1. Kliknij Rebasei módl się, żeby nie było konfliktów, połącz, jeśli musisz.

  2. Wciśnij zmiany, w tym momencie wszystkie wersje powinny nadal być draft.

  3. Przejdź do najwyższej wersji w gałęzi, do której przenosiłeś zmiany Right Mouse-> Change Phase to-> Public.

wprowadź opis obrazu tutaj

Mam nadzieję, że zaoszczędzi ci to trochę czasu.

Matas Vaitkevicius
źródło
Dobra robota! mam zamiar spróbować, tylko jedno pytanie - po co na końcu zmienić tę fazę na publiczną? „Wszelkie zestawy zmian widoczne w zdalnym repozytorium są publiczne”, więc czy w przypadku naciśnięcia przycisku nie zostaną one ustawione jako publiczne?
Joshua Duxbury
@JoshLeeDucks Kiedy pchają, nie zmieniają się publicjuż na automagicznie (przynajmniej dla mnie tak się nie dzieje).
Matas Vaitkevicius