Jak znaleźć kolejne zatwierdzenie w git? (dziecko / dzieci referencyjne)

ref^odnosi się do zatwierdzenia wcześniej ref, a co z uzyskaniem zatwierdzenia po ref ?

Na przykład, jeśli git checkout 12345mam sprawdzić następny zatwierdzenie?

Dzięki.

PS Tak, git to drzewo struktury wskaźnika węzła DAG. Jak znaleźć zatwierdzenie po tym?

Aby wyświetlić listę wszystkich zatwierdzeń, zaczynając od bieżącego, a następnie jego potomka itd. - w zasadzie standardowy dziennik git, ale idąc w drugą stronę, użyj czegoś w rodzaju

git log --reverse --ancestry-path 894e8b4e93d8f3^..master

gdzie 894e8b4e93d8f3 jest pierwszym zatwierdzeniem, które chcesz pokazać.

Twórca Hudson (obecnie Jenkins) Kohsuke Kawaguchi właśnie opublikował (listopad 2013):
kohsuke / git-children-of :

Biorąc pod uwagę zatwierdzenie, znajdź bezpośrednie dzieci tego zatwierdzenia.

#!/bin/bash -e
# given a commit, find immediate children of that commit.
for arg in "$@"; do
  for commit in $(git rev-parse $arg^0); do
    for child in $(git log --format='%H %P' --all | grep -F " $commit" | cut -f1 -d' '); do
      git describe $child
    done
  done
done

Jak ilustruje ten wątek , w VCS opartym na historii reprezentowanej przez DAG (Directed Acyclic Graph) nie ma „jednego rodzica” ani „jednego dziecka”.

        C1 -> C2 -> C3
      /               \
A -> B                  E -> F
      \               /
        D1 -> D2 ----/

Kolejność zatwierdzeń odbywa się poprzez „zamówienie topo” lub „zamówienie według daty” (patrz książka GitPro )

Ale od wersji Git 1.6.0 możesz wyświetlić listę potomków zatwierdzenia.

git rev-list --children
git log --children

Uwaga: w przypadku zatwierdzeń nadrzędnych występuje ten sam problem, z sufiksem ^parametru zmiany oznaczającego pierwszego rodzica tego obiektu zatwierdzenia. ^<n>oznacza <n>th rodzica (tj. rev^ jest równoważne rev^1).

Jeśli jesteś w oddziale fooi wydajesz „ git merge bar”, to foobędziesz pierwszym rodzicem.
Tj .: pierwszy element nadrzędny to gałąź, w której byłeś podczas scalania, a drugi to zatwierdzenie w gałęzi, w której się scaliłeś.

znalazłem to

git rev-list --ancestry-path commit1..commit2

gdzie ustawiłem commit1jako bieżące zatwierdzenie i commit2do aktualnej głowy. To zwraca mi listę wszystkich zatwierdzeń, które budują ścieżkę pomiędzy commit1a commit2.

Ostatni wiersz wyniku to potomek commit1 (na ścieżce do commit2).

Wiem co masz na myśli. Frustrujące jest posiadanie dużej składni do przechodzenia do poprzednich zatwierdzeń, ale nie przechodzenie do następnych. W złożonej historii problem „co to jest kolejne zatwierdzenie” staje się raczej trudny, ale w złożonym łączeniu pojawia się ta sama twardość z „poprzednimi” zobowiązaniami. W prostym przypadku w obrębie jednej gałęzi z liniową historią (nawet tylko lokalnie dla pewnej ograniczonej liczby zatwierdzeń) byłoby miło i sensownie byłoby iść do przodu i do tyłu.

Prawdziwym problemem jest jednak to, że do zatwierdzeń potomnych nie ma odniesienia, jest to tylko lista powiązana wstecz. Znalezienie zatwierdzenia potomnego wymaga wyszukiwania, co nie jest takie złe, ale prawdopodobnie nie jest czymś, co git chce umieścić w logice refspec.

W każdym razie natknąłem się na to pytanie, ponieważ chcę po prostu zrobić krok naprzód w historii, dokonując pojedynczych naruszeń, wykonując testy, a czasem trzeba zrobić krok naprzód, a nie wstecz. Po dłuższym zastanowieniu wymyśliłem to rozwiązanie:

Wybierz zatwierdzenie przed miejscem, w którym jesteś. Prawdopodobnie może to być głowa oddziału. Jeśli jesteś w oddziale ~ 10, to „git checkout branch ~ 9”, a następnie „git checkout branch ~ 8”, aby uzyskać następny, a następnie „git checkout branch ~ 7” i tak dalej.

Zmniejszenie liczby powinno być naprawdę łatwe w skrypcie, jeśli jest to potrzebne. O wiele łatwiej niż parsowanie git rev-list.

Dwie praktyczne odpowiedzi:

Jedno dziecko

Na podstawie odpowiedzi @ Michaela zhakowałem childalias w swoim .gitconfig.

Działa zgodnie z oczekiwaniami w przypadku domyślnym, a także jest wszechstronny.

# Get the child commit of the current commit.
# Use $1 instead of 'HEAD' if given. Use $2 instead of curent branch if given.
child = "!bash -c 'git log --format=%H --reverse --ancestry-path ${1:-HEAD}..${2:\"$(git rev-parse --abbrev-ref HEAD)\"} | head -1' -"

Domyślnie podaje potomka HEAD (chyba że podano inny argument zatwierdzenia), wykonując przodek o krok w kierunku końca bieżącej gałęzi (chyba że drugi argument zatwierdzenia jest podany jako drugi argument).

Użyj %hzamiast, %Hjeśli chcesz mieć krótki formularz skrótu.

Wiele dzieci

Z odłączoną GŁOWĄ (nie ma gałęzi) lub aby uzyskać wszystkie dzieci niezależnie od gałęzi:

# For the current (or specified) commit-ish, get the all children, print the first child 
children = "!bash -c 'c=${1:-HEAD}; set -- $(git rev-list --all --not \"$c\"^@ --children | grep $(git rev-parse \"$c\") ); shift; echo $1' -"

Zmień na, $1aby $*wydrukować wszystkie dzieci.

Możesz także zmienić --allna zatwierdzenie, aby wyświetlać tylko dzieci, które są przodkami tego zatwierdzenia - innymi słowy, aby wyświetlać tylko dzieci „w kierunku” danego zatwierdzenia. Może to pomóc zawęzić wyniki od wielu dzieci do jednego.

Nie ma unikalnego „następnego zatwierdzenia”. Ponieważ historia w Git jest DAG, a nie wierszem, wiele zatwierdzeń może mieć wspólnego rodzica (gałęzie), a zatwierdzenia mogą mieć więcej niż jednego rodzica (scalenia).

Jeśli masz na myśli konkretną gałąź, możesz spojrzeć na jej log i zobaczyć, co zatwierdza na liście obecną jako nadrzędną.

Wypróbowałem wiele różnych rozwiązań i żadne nie działało dla mnie. Musiałem wymyślić własne.

znajdź następny zatwierdzenie

function n() {
    git log --reverse --pretty=%H master | grep -A 1 $(git rev-parse HEAD) | tail -n1 | xargs git checkout
}

znajdź poprzednie zatwierdzenie

function p() {
    git checkout HEAD^1
}

W przypadku, gdy nie masz na myśli konkretnego zatwierdzenia „docelowego”, ale zamiast tego chcesz zobaczyć zatwierdzenia potomne, które mogą znajdować się w dowolnej gałęzi, możesz użyć tego polecenia:

git rev-list --children --all | grep ^${COMMIT}

Jeśli chcesz zobaczyć wszystkie dzieci i wnuki , musisz użyć rev-list --childrenrekurencyjnie:

git rev-list --children --all | \
egrep ^\($(git rev-list --children --all | \
           grep ^${COMMIT} | \
           sed 's/ /|/g')\)

(Wersja, która daje tylko wnuczki, użyłaby bardziej złożonego sedi / lub cut.)

Na koniec możesz wprowadzić to do log --graphpolecenia, aby zobaczyć strukturę drzewa, w następujący sposób:

git log --graph --oneline --decorate \
\^${COMMIT}^@ \
$(git rev-list --children --all | \
  egrep ^\($(git rev-list --children --all | \
             grep ^${COMMIT} | \
             sed 's/ /|/g')\))

Uwaga : wszystkie powyższe polecenia zakładają, że zmienna powłoki została ustawiona na ${COMMIT}jakieś odniesienie (gałąź, znacznik, sha1) zatwierdzenia, którego dziećmi jesteś zainteresowany.

(Zaczęło się to jako odpowiedź na zduplikowane pytanie. Przeprowadziłem trochę lekkiej edycji, aby je oczyścić).

Wszystkie wewnętrzne strzałki Gita są jednokierunkowe, skierowane do tyłu. Dlatego nie ma krótkiej wygodnej składni do poruszania się do przodu: to po prostu niemożliwe.

Możliwe jest „poruszanie się przeciw strzałom”, ale sposób na zrobienie tego jest zaskakujący, jeśli nie widziałeś go wcześniej, a potem oczywisty później. Powiedzmy, że mamy:

A <-B <-C <-D <-E   <-- last
        ^
        |
         \--------- middle

Używanie middle~2następuje dwukrotnie zgodnie ze strzałkami od Ctyłu do A. Więc jak możemy przenieść Csię D? Odpowiedź brzmi: zaczynamy od E, używając nazwy lasti pracujemy wstecz, aż do niej dojdziemy middle, rejestrując punkty, które odwiedzamy po drodze . Następnie poruszamy się tak daleko, jak chcemy, w kierunku last: przesuń się o jeden krok Dlub dwa do E.

Jest to szczególnie ważne, gdy mamy oddziały:

          D--E   <-- feature1
         /
...--B--C   <-- master
         \
          F--G   <-- feature2

Który zatwierdzenie jest krok po kroku C? Nie ma poprawnej odpowiedzi, dopóki nie dodasz do pytania: w kierunku cechy___ (wypełnij puste pole).

Aby wyliczyć commits pomiędzy C(wykluczając C) samą i, powiedzmy, Gużywamy:

git rev-list --topo-order --ancestry-path master..feature2

W --topo-ordergwarantuje, że nawet w obecności złożonego rozgałęzienia i-łączących się commity wyjdzie w topologicznie-posortowanych. Jest to wymagane tylko wtedy, gdy łańcuch nie jest liniowy. Te --ancestry-pathśrodki ograniczające że gdy pracujemy z tyłu feature2, tylko commity list, które mają zobowiązać Cjako jeden z ich własnych przodków. To znaczy, jeśli wykres - lub jego odpowiednia część - faktycznie wygląda tak:

A--B--C   <-- master
 \     \
  \     F--G--J   <-- feature2
   \         /
    H-------I   <-- feature3

prosty wniosek formie feature2..masterwylicza zobowiązuje J, Ga I, a F, a Hw pewnym porządku. Z --ancestry-pathnokautujemy Hi I: nie są potomkami C, tylko z A. Dzięki --topo-ordernam upewnić się, że rzeczywista kolejność jest wyliczenie J, potem G, potem F.

git rev-listKomenda wycieki tych identyfikatorów hash na standardowe wyjście, po jednej w wierszu. Aby przejść o krok do przodu w kierunku feature2, chcemy tylko ostatniej linii.

Jest możliwe (i kuszące i może być użyteczne) dodawanie, --reversedzięki czemu git rev-listpo wygenerowaniu drukuje zatwierdzenia w odwrotnej kolejności. To działa, ale jeśli używasz go w potoku takim jak ten:

git rev-list --topo-order --ancestry-path --reverse <id1>...<id2> | head -1

aby uzyskać „następny zatwierdzenie w kierunku id2”, a istnieje bardzo długa lista zatwierdzeń, git rev-listpolecenie może uzyskać zepsuty potok, gdy próbuje zapisać, do headktórego przestał czytać dane wejściowe i zakończył działanie. Ponieważ błędy w potokach są zwykle ignorowane przez powłokę, działa to głównie. Tylko upewnij się, że są ignorowane w twoim użyciu.

Kuszące jest także dodanie -n 1do git rev-listpolecenia wraz z --reverse. Nie rób tego! To git rev-listzatrzymuje się po przejściu o jeden krok wstecz , a następnie odwróceniu (jednopunktowej) listy odwiedzonych zatwierdzeń. Tak powstaje za <id2>każdym razem.

Ważna uwaga dodatkowa

Zauważ, że w przypadku fragmentów graficznych „diament” lub „pierścień benzenowy”:

       I--J
      /    \
...--H      M--...  <-- last
      \    /
       K--L

przesunięcie jednego zatwierdzenia „do przodu” z w Hkierunku lastspowoduje albo I albo K . Nic nie możesz na to poradzić: oba zobowiązania są o krok do przodu! Jeśli następnie zaczniesz od wynikowego zatwierdzenia i przejdziesz do następnego kroku, jesteś teraz zaangażowany w dowolną ścieżkę, którą zacząłeś.

Lekarstwem na to jest unikanie przemieszczania się o krok i blokowanie łańcuchów zależnych od ścieżki. Zamiast tego, jeśli planujesz odwiedzić cały łańcuch ścieżki przodków, zanim zrobisz cokolwiek innego , utwórz pełną listę wszystkich zatwierdzeń w łańcuchu:

git rev-list --topo-order --reverse --ancestry-path A..B > /tmp/list-of-commits

Następnie odwiedzaj każdy zatwierdzenie na tej liście, pojedynczo, a otrzymasz cały łańcuch. --topo-orderZadba trafisz I-i- Jw tej kolejności, a K-i- Lw tej kolejności (choć nie ma łatwego sposobu, aby przewidzieć, czy zrobisz parę IJ przed lub po parę KL).

Mam ten alias w ~/.gitconfig

first-child = "!f() { git log  --reverse --ancestry-path --pretty=%H $1..${2:-HEAD} | head -1; }; f"

Udało mi się znaleźć następne dziecko w następujący sposób:

git log --reverse --children -n1 HEAD (where 'n' is the number of children to show)

Jeśli wszystkie zatwierdzenia potomne znajdują się w jakiejś gałęzi, możesz użyć gitk --all commit^.., gdzie „zatwierdzenie” jest czymś identyfikującym zatwierdzenie. Na przykład, jeśli skrót SHA-1 zatwierdzenia to c6661c5, wpiszgitk --all c6661c5^..

Prawdopodobnie będziesz musiał wprowadzić pełny SHA-1 w komórce gitk „SHA1 ID:”. Będziesz potrzebował pełnego SHA-1, który w tym przykładzie można uzyskać za pośrednictwemgit rev-parse c6661c5

Alternatywnie, git rev-list --all --children | grep '^c6661c5883bb53d400ce160a5897610ecedbdc9d'stworzy wiersz zawierający wszystkie dzieci tego zatwierdzenia, przypuszczalnie bez względu na to, czy w grę wchodzi oddział.

Każde zatwierdzenie przechowuje wskaźnik do swojego elementu nadrzędnego (rodziców, w przypadku zatwierdzenia scalania (standard)).

Zatem nie ma sposobu, aby wskazać zatwierdzenie dziecka (jeśli istnieje) od rodzica.

Ten post ( http://www.jayway.com/2015/03/30/using-git-commits-to-drive-a-live-coding-session/#comment-282667 ) pokazuje fajny sposób, jeśli robisz to, jeśli możesz utworzyć dobrze zdefiniowany znacznik na końcu stosu zatwierdzeń. Zasadniczo git config --global alias.next '!git checkout `git rev-list HEAD..demo-end | tail -1`' gdzie „demo-end” jest ostatnim tagiem.

Istniejące odpowiedzi zakładają, że masz gałąź zawierającą szukany zatwierdzenie.

W moim przypadku zatwierdzenie, którego szukałem, nie było włączone, git rev-list --allponieważ żadna gałąź tego nie zawierała.

Skończyłem przeglądać gitk --reflogręcznie.

Jeśli nie możesz znaleźć swojego zatwierdzenia nawet w dzienniku, spróbuj:

• git fsck --full aby wyświetlić listę zwisających (tzn. nie w żadnej gałęzi) zatwierdzeń, lub
• git fsck --lost-found zrobić referencje wskazujące na wiszące zobowiązania do zastosowania technik w innych odpowiedziach.