Począwszy od Gita w wersji 2.5+ (Q2 2015), pobieranie pojedynczego zatwierdzenia (bez klonowania pełnego repozytorium) jest faktycznie możliwe.
Zobacz commit 68ee628, autor: Fredrik Medley ( moroten
) , 21 maja 2015 r.
(Scalony przez Junio C Hamano - gitster
- w commit a9d3493 , 01 czerwca 2015)
Masz teraz nową konfigurację (po stronie serwera)
uploadpack.allowReachableSHA1InWant
Pozwól, upload-pack
aby zaakceptować żądanie pobierania, które prosi o obiekt, który jest osiągalny z dowolnej wskazówki. Należy jednak pamiętać, że obliczanie osiągalności obiektów jest drogie obliczeniowo.
Domyślnie to false
.
Jeśli połączysz tę konfigurację po stronie serwera z płytkim klonowaniem ( git fetch --depth=1
), możesz poprosić o pojedynczy zatwierdzenie (patrz t/t5516-fetch-push.sh
:
git fetch --depth=1 ../testrepo/.git $SHA1
Możesz użyć git cat-file
polecenia, aby zobaczyć, że zatwierdzenie zostało pobrane:
git cat-file commit $SHA1
Polecenie „ git upload-pack
”, które służy ” git fetch
może służyć do zatwierdzania zatwierdzeń, które nie znajdują się na końcu żadnego odwołania, o ile są one dostępne z polecenia, przy uploadpack.allowReachableSHA1InWant
zmiennej konfiguracyjnej.
Pełna dokumentacja to:
upload-pack
: opcjonalnie zezwól na pobieranie osiągalnego sha1
Po uploadpack.allowReachableSHA1InWant
ustawieniu opcji konfiguracyjnej po stronie serwera „ git fetch
” może wysłać zapytanie za pomocą wiersza „want”, który nazywa obiekt, który nie był reklamowany (prawdopodobnie został pozyskany poza pasmem lub ze wskaźnika submodułu). Przetwarzane będą
tylko obiekty osiągalne z wierzchołków gałęzi, tj. Połączenie reklamowanych gałęzi i ukrytych gałęzi transfer.hideRefs
.
Pamiętaj, że wiąże się to z koniecznością przeglądania historii w celu sprawdzenia osiągalności.
Tej funkcji można użyć przy uzyskiwaniu zawartości określonego zatwierdzenia, dla którego znany jest sha1, bez potrzeby klonowania całego repozytorium, szczególnie jeśli używane jest płytkie pobieranie .
Przydatnymi przypadkami są np
- repozytoria zawierające duże pliki w historii,
- pobieranie tylko potrzebnych danych do kasy podmodułowej,
- dzieląc sha1 bez informowania, do której dokładnie gałęzi należy, i w Gerrit, jeśli myślisz w kategoriach zatwierdzeń zamiast zmiany liczb.
(Sprawa Gerrit została już rozwiązana, allowTipSHA1InWant
ponieważ każda zmiana Gerrit ma ref.)
Git 2.6 (III kwartał 2015) ulepszy ten model.
Zobacz zatwierdzenie 2bc31d1 , zatwierdzenie cc118a6 (28 lipca 2015 r.) Autor: Jeff King ( peff
) .
(Połączone przez Junio C Hamano - gitster
- w commit 824a0be , 19 sierpnia 2015)
refs
: wsparcie negatywne transfer.hideRefs
Jeśli ukryjesz hierarchię referencji za pomocą transfer.hideRefs
config, nie ma możliwości późniejszego zastąpienia tej konfiguracji, aby ją „odkryć”.
Ta łatka implementuje „negatywne” ukrywanie, które powoduje, że mecze są natychmiast oznaczane jako ukryte, nawet jeśli inne dopasowanie je ukryje.
Dbamy o stosowanie dopasowań w odwrotnej kolejności od sposobu, w jaki są one dostarczane do nas przez maszynę konfiguracyjną, ponieważ pozwala to naszej zwykłej pracy na „ostatnią wygrywa” konfigurację (a wpisy w .git/config
, na przykład, zostaną zastąpione /etc/gitconfig
).
Możesz teraz zrobić:
git config --system transfer.hideRefs refs/secret
git config transfer.hideRefs '!refs/secret/not-so-secret'
aby ukryć się refs/secret
we wszystkich repozytoriach, z wyjątkiem jednego publicznego bitu w jednym konkretnym repozytorium.
Git 2.7 (listopad / grudzień 2015) poprawi się ponownie:
Zobacz zatwierdzenie 948bfa2 , zatwierdzenie 00b293e (05 listopada 2015), zatwierdzenie 78a766a , zatwierdzenie 92cab49 , zatwierdzenie 92cab49 , zatwierdzenie 92cab49 (03 listopada 2015), zatwierdzenie 00b293e , zatwierdzenie 00b293e (05 listopada 2015) i zatwierdzenie 92cab49 , zatwierdzenie 92cab49 , zatwierdzenie 92cab49 , commit 92cab49 (03 listopada 2015) autor: Lukas Fleischer ( lfos
) .
Pomógł: Eric Sunshine ( sunshineco
) .
(Scalony przez Jeff King - peff
- in commit dbba85e , 20 listopada 2015)
config.txt
: udokumentuj semantykę za hideRefs
pomocą przestrzeni nazw
W tej chwili nie ma jasnej definicji tego, jak transfer.hideRefs
powinno się zachowywać po ustawieniu przestrzeni nazw.
Wyjaśnij, że hideRefs
w tym przypadku przedrostki pasują do pozbawionych nazw. W ten sposób hideRefs
wzorce są obecnie obsługiwane w pakiecie odbiorczym.
hideRefs: dodaj obsługę pasujących pełnych referencji
Oprócz pasujących hideRefs
referencji w paski można teraz dodawać wzory, z którymi dopasowywana jest pełna referencja (bez pasów).
Aby rozróżnić dopasowania rozłożone i pełne, te nowe wzorce muszą być poprzedzone znakiem circumflex ( ^
).
Stąd nowa dokumentacja :
transfer.hideRefs:
Jeśli używana jest przestrzeń nazw, prefiks przestrzeni nazw jest usuwany z każdego odwołania przed dopasowaniem do transfer.hiderefs
wzorców.
Na przykład, jeśli refs/heads/master
jest określony w transfer.hideRefs
a obecna przestrzeń nazw foo
, a następnie refs/namespaces/foo/refs/heads/master
został pominięty z reklam, ale refs/heads/master
i
refs/namespaces/bar/refs/heads/master
nadal są reklamowane jako tzw „mieć” linii.
Aby dopasować ^
referencje przed usunięciem, dodaj przed nazwą referencji. Jeśli połączysz !
i ^
, !
musisz najpierw określić.
R .. wspomina w komentarzach o konfiguracji uploadpack.allowAnySHA1InWant
, która pozwala upload-pack
zaakceptować fetch
żądanie, które w ogóle prosi o dowolny obiekt. (Domyślnie false
).
Zobacz commit f8edeaa (listopad 2016, Git v2.11.1) autorstwa Davida „novalis” Turnera ( novalis
) :
upload-pack
: opcjonalnie zezwól na pobieranie dowolnego sha1
Trochę głupio wydaje się sprawdzanie osiągalności w przypadku, gdy ufamy, że użytkownik uzyska dostęp do absolutnie wszystkiego w repozytorium.
Co więcej, jest to dość ryzykowne w systemie rozproszonym - być może jeden serwer reklamuje ref, ale od tego czasu inny został zmuszony do tego ref, a być może dwa żądania HTTP są skierowane do tych różnych serwerów.