Jak znaleźć hash gałęzi w Git?

Biorąc pod uwagę nazwę gałęzi lokalnej / zdalnej, jak mogę uzyskać skrót zatwierdzenia, na który wskazuje ta gałąź?

Komenda git rev-parsejest Twoim przyjacielem, np:

$ git rev-parse development
17f2303133734f4b9a9aacfe52209e04ec11aff4

... lub dla oddziału zdalnego śledzenia:

$ git rev-parse origin/master
da1ec1472c108f52d4256049fe1f674af69e785d

To polecenie jest ogólnie bardzo przydatne, ponieważ może przeanalizować dowolny ze sposobów określania nazw gałęzi git, na przykład:

git rev-parse master~3
git rev-parse HEAD@{2.days.ago}

... itd.

Skróty są przechowywane pod .git/refs/ np.git/refs/heads/master

Ale używaj programowo git rev-parsezgodnie z sugestią Marka Longaira, ponieważ jest to bezpieczniejsze.

Nie zapominaj, że od Git 2.19 (Q2 2018), Git przygotowuje przejście z SHA1 do SHA2: zobacz „ Dlaczego Git nie używa nowocześniejszego SHA? "

Z Git 2.25 (Q1 2020), git rev-parse ewoluuje i odzwierciedla ten możliwy nowy hash.

Zobacz popełnić fa26d5e , popełnić cf02be8 , popełnić 38ee26b , popełnić 37ab8eb , popełnić 0370b35 , popełnić 0253e12 , popełnić 45e2ef2 , popełnić 79b0edc , popełnić 840624f , popełnić 32a6707 , popełnić 440bf91 , popełnić 0b408ca , popełnić 2eabd38 (28 paź 2019) i popełnić 1bcef51 , zobowiązać ecde49b (5 października 2019) autor: brian m. carlson ( bk2204) .
^{(Scalony przez Junio ​​C Hamano - gitster- w zatwierdzeniu 28014c1, 10 listopada 2019)}

rev-parse: dodaj --show-object-formatopcję

^{Podpisał: brian m. Carlson}

Dodaj opcję drukowania formatu obiektu używanego do wejścia, wyjścia lub przechowywania.
Pozwala to skryptom powłoki wykryć używany algorytm skrótu.

Ponieważ plan przejścia dopuszcza wiele algorytmów wejściowych, udokumentuj, że możemy dostarczyć wiele wyników wejściowych oraz format, jaki mogą przyjąć te wyniki.
Chociaż nie obsługujemy tego teraz, udokumentowanie tego wcześnie oznacza, że ​​autorzy skryptów mogą zabezpieczyć swoje skrypty w przyszłości, gdy to zrobimy.

git rev-parseDokumentacja obejmuje obecnie:

--show-object-format[=(storage|input|output)]:

Pokaż format obiektu (algorytm skrótu) używany dla repozytorium do przechowywania w .gitkatalogu, wejściu lub wyjściu. Dla danych wejściowych można wydrukować wiele algorytmów, oddzielonych spacjami. Jeśli nie zostanie określony, domyślną wartością jest „pamięć”.

Dzięki Git 2.29 (Q4 2020) możesz upewnić się, jakiego formatu musisz użyć do odczytania haszującego zatwierdzenia gałęzi (lub dowolnego innego obiektu).

Zobacz popełnić e023ff0 , popełnić 4feb562 , popełnić 8a06d56 , popełnić c49fe07 , popełnić 02a32db , popełnić ceaa4b3 , popełnić eff45da , popełnić b5b46d7 , popełnić c5aecfc , popełnić e74b606 , popełnić 439d3a1 , popełnić 6c2adf8 , popełnić de5737c , popełnić e0a646e , popełnić 6ff6a67 , popełnić 831279d , zobowiązać b6e5005 , zatwierdzenie 287bb3a , zatwierdzenie 22f1824 , zatwierdzenie db00af9 ,zatwierdzić 7187eb1 , zatwierdzić 98de0b2 , zatwierdzić a5587b8 , zatwierdzić 66b6d43 , zatwierdzić 2197f87 , zatwierdzić c0b65ea , zatwierdzić d62607d , zatwierdzić d482c23 , zatwierdzić 866be6e , zatwierdzić 4bacb6d , zatwierdzić 252a4ee , zatwierdzić 368f3cb , zatwierdzić c0b65ea , zatwierdzić d62607d , zatwierdzić d482c23 , zatwierdzić 866be6e , zatwierdzić 4bacb6d , zatwierdzić 252a4ee , zatwierdzić 368f3cb , zatwierdzić abe3dbc1 , zatwierdzić , commit 094a685 (29 lipca 2020) autor: brian bk2204M. carlson ( ) .
Widziećpopełnij 800e6a7 (29 lipca 2020) przez Johannes Schindelin ( dscho) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu e0ad957 , 11 sierpnia 2020 r.)}

docs: dodaj dokumentację dla extensions.objectFormat

^{Podpisał: brian m. carlson Recenzent
: Eric Sunshine}

Udokumentuj extensions.objectFormatustawienia konfiguracji.
Ostrzegaj użytkowników, aby sami go nie modyfikowali.

git configteraz zawiera na swojej stronie podręcznika :

extensions.objectFormat

Określ algorytm wyznaczania wartości skrótu do użycia.

Dopuszczalne wartości to sha1i> sha256.
Jeśli nie określono, sha1przyjmuje się.
Podanie tego klucza core.repositoryFormatVersionjest błędem, chyba że jest to 1.

Zauważ, że to ustawienie powinno być ustawione tylko przez git initlub git clone.
Próba zmiany go po inicjalizacji nie zadziała i spowoduje problemy trudne do zdiagnozowania.

Dla jasności, w Git 2.29 (Q4 2020), niedawny dodatek wsparcia SHA-256 jest oznaczony w dokumentacji jako eksperymentalny .

Zobacz commit ff233d8 (16 sierpnia 2020) autorstwa Martina Ågren ( none) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zatwierdzeniu d1ff741 , 24 sierpnia 2020 r.)}

Documentation: oznacz --object-format=sha256jako eksperymentalne

^{Podpisał: Martin Ågren}

Po eff45daab8 (" repository: domyślnie włącz obsługę SHA-256", 2020-07-29, Git v2.29.0 - scalanie wymienione w partii nr 6 ), proste kompilacje Gita umożliwiają użytkownikowi uruchomienie, np.

git init --object-format=sha256  

i odhakuj.
Może to być dobry sposób na zdobycie doświadczenia w świecie SHA-256, np. W celu znalezienia błędów

GIT_TEST_DEFAULT_HASH=sha256 make test  

nie zauważa.

Ale to naprawdę odrębny świat: takie repozytoria SHA-256 będą działać całkowicie niezależnie od (już dość dużego) zestawu repozytoriów SHA-1.
Interakcja ponad granicami jest w zasadzie możliwa, np. Za pomocą „ diff+ apply” (lub „ format-patch+ am”), ale nawet to ma swoje ograniczenia: zastosowanie różnicy SHA-256 w repozytorium SHA-1 działa w prostym przypadku, ale jeśli musisz się uciec -3, nie masz szczęścia.

Podobnie, „ push+ pull” powinno działać, ale tak naprawdę będziesz działać głównie z przesunięciem względem reszty świata. To może być w porządku przed zainicjowaniem repozytorium i może być w porządku przez kilka miesięcy po tym, ale może nadejść dzień, kiedy zaczniesz żałować użycia [git init --object-format = sha256 ](https://github.com/git/git/blob/ff233d8dda12657a90d378f2b403bc6c85838c59/Documentation/git-init.txt#L52)<sup>([man](https://git-scm.com/docs/git-init#Documentation/git-init.txt---object-formatltformatgt))</sup>i wkopałeś się w dość głęboką dziurę.

Obecnie trwają prace nad dokumentacją naszych formatów danych i protokołów dotyczących SHA-256, aw niektórych przypadkach (midx i wykres zatwierdzeń) rozważamy dostosowanie sposobu, w jaki formaty plików wskazują, którego formatu obiektu użyć.

Wszędzie --object-formattam, gdzie jest mowa w naszej dokumentacji, wyjaśnijmy, że używanie go z "sha256" jest eksperymentalne.
Jeśli później będziemy musieli wyjaśnić, dlaczego nie możemy obsłużyć danych, które wygenerowaliśmy w 2020 roku, zawsze możemy wskazać ten akapit, który tutaj dodajemy.

Poprzez „include ::” - krótką notkę, powinniśmy być w stanie zachować spójność w całej dokumentacji i ostatecznie stopniowo złagodzić wagę tego tekstu.
Pewnego dnia możemy nawet użyć go do wycofania się --object-format=sha1, ale nie wyprzedzajmy siebie ...

Jest też extensions.objectFormat, ale wspomniano o tym tylko trzy razy. Dwukrotnie dodajemy to nowe zastrzeżenie, aw trzecim miejscu mamy już ostrzeżenie „nie edytuj”. Stamtąd zainteresowani czytelnicy powinni w końcu znaleźć ten nowy, który tutaj dodajemy.

Ponieważ GIT_DEFAULT_HASHzapewnia kolejny punkt wejścia do tej funkcji, udokumentuj również jej eksperymentalny charakter.

gitteraz zawiera na swojej stronie podręcznika :

jest używany zamiast tego. Wartość domyślna to „sha1”. TA ZMIENNA JEST EKSPERYMENTALNA! Zobacz --object-formatw git init.

object-format-disclaimerteraz zawiera na swojej stronie podręcznika :

TA OPCJA JEST EKSPERYMENTALNA!
Obsługa SHA-256 jest eksperymentalna i wciąż znajduje się na wczesnym etapie.

Repozytorium SHA-256 na ogół nie będzie w stanie> udostępniać pracy „zwykłym” repozytoriom SHA-1.
Należy założyć, że np. Wewnętrzne formaty plików Git w stosunku do repozytoriów SHA-256 mogą się zmieniać w sposób niekompatybilny wstecz.
Używać tylko --object-format=sha256do celów testowych.

Ten sam Git 2.29 (Q4 2020) zapewnia, że ​​" git clone" ^{( man )} będzie działał, gdy jeden klonuje z repozytorium SHA-1, podczas gdy GIT_DEFAULT_HASHjest już ustawiony na używanie SHA-256.
Przed 2.29 skutkowało to bezużytecznym repozytorium, które częściowo twierdziło, że jest repozytorium SHA-256 z obiektami i referencjami SHA-1.
Zostało to poprawione.

Patrz popełnienia 47ac970 (20 wrzesień 2020) przez brian m. carlson ( bk2204) .
^{(Scalone przez Junio ​​C Hamano - gitster- w zobowiązaniu b28919c , 29 września 2020 r.)}

builtin/clone: unikaj awarii z GIT_DEFAULT_HASH

^{Zgłoszone przez: Matheus Tavares
Podpisane przez: brian m. Carlson}

Jeśli użytkownik klonuje repozytorium SHA-1 z GIT_DEFAULT_HASHustawieniem na „ sha256”, możemy otrzymać repozytorium, w którym wersja formatu repozytorium to 0, ale extensions.objectformatklucz jest ustawiony na „ sha256”.
Jest to zarówno błędne (użytkownik ma repozytorium SHA-1), jak i niefunkcjonalne (ponieważ rozszerzenia nie można używać w repozytorium v0).

Dzieje się tak, ponieważ w klonie początkowo konfigurujemy repozytorium, a następnie zmieniamy jego algorytm na podstawie tego, co strona zdalna mówi nam, że używa.
W tym przypadku początkowo ustawiliśmy repozytorium jako SHA-256, a później zresetowaliśmy wersję repozytorium bez czyszczenia rozszerzenia.

W tym przypadku zawsze moglibyśmy ustawić rozszerzenie, ale oznaczałoby to, że nasze repozytoria SHA-1 nie byłyby kompatybilne ze starszymi wersjami Gita, mimo że nie ma powodu, dla którego nie powinny.
Nie chcemy też początkowo inicjalizować repozytorium jako SHA-1, ponieważ oznacza to, że jeśli klonujemy puste repozytorium, nie uda nam się uszanować GIT_DEFAULT_HASHzmiennej i otrzymamy repozytorium SHA-1, a nie repozytorium SHA-256.

Żadne z nich nie jest atrakcyjne, więc powiedzmy kodowi inicjalizacji repozytorium, jeśli robimy taką reinitację, a jeśli tak, wyczyść rozszerzenie, jeśli używamy SHA-1.
Daje to pewność, że tworzymy prawidłowe i funkcjonalne repozytorium i nie psuje żadnego z naszych innych przypadków użycia.