Uwaga: począwszy od git 1.9 / 2.0 (Q1 2014) , git fetch --tags
pobiera tagi oprócz tego, co jest pobierane przez ten sam wiersz poleceń bez opcji.
Zobacz zatwierdzenie c5a84e9 przez Michael Haggerty (mhagger) :
Poprzednio --tags
opcja pobierania „ ” była uważana za równoważną z określeniem parametru refspec
refs/tags/*:refs/tags/*
w wierszu poleceń; w szczególności spowodowało remote.<name>.refspec
to zignorowanie konfiguracji.
Ale to nie jest bardzo przydatna do pobierania tagów bez pobierania również inne odniesienia, podczas gdy to jest bardzo przydatne, aby móc pobrać tagów oprócz innych odniesień.
Więc zmień semantykę tej opcji, aby zrobić to drugie.
Jeśli użytkownik chce pobrać tylko tagi, nadal można określić jawny refspec:
git fetch <remote> 'refs/tags/*:refs/tags/*'
Należy pamiętać, że dokumentacja sprzed 1.8.0.3 była niejednoznaczna co do tego aspektu fetch --tags
zachowania.
Zatwierdzenie f0cb2f1 ( 14.12.2012 ) fetch --tags
spowodowało, że dokumentacja jest zgodna ze starym zachowaniem.
To zatwierdzenie zmienia dokumentację w celu dopasowania do nowego zachowania (patrz Documentation/fetch-options.txt
).
Zażądaj, aby wszystkie tagi były pobierane z pilota oprócz wszystkiego, co jest pobierane .
Ponieważ Git 2.5 (Q2 2015) git pull --tags
jest bardziej niezawodny:
Zob. Zatwierdzenie 19d122b przez Paula Tana ( pyokagan
) , 13 maja 2015 r.
(Scalony przez Junio C Hamano - gitster
- w commit cc77b99 , 22 maja 2015 r.)
pull
: usuń --tags
błąd w przypadku braku scalania kandydatów
Ponieważ 441ed41 („ git pull --tags
”: błąd z lepszym komunikatem., 2007-12-28, Git 1.5.4+), git pull --tags
wydrukowałby inny komunikat o błędzie, gdyby
git-fetch
nie zwrócił żadnych kandydatów do scalenia:
It doesn't make sense to pull all tags; you probably meant:
git fetch --tags
Wynika to z tego, że w tym czasie git-fetch --tags
zastąpiłyby wszystkie skonfigurowane parametry referencyjne, a zatem nie byłoby kandydatów do scalenia. W ten sposób wprowadzono komunikat o błędzie, aby zapobiec pomyłkom.
Jednak ponieważ c5a84e9 ( fetch --tags
: pobieraj tagi oprócz
innych rzeczy, 2013-10-30, Git 1.9.0+), git fetch --tags
pobierałby tagi oprócz wszelkich skonfigurowanych refspecs.
Stąd, jeśli nie wystąpi żadna sytuacja kandydatów do scalenia, to nie dlatego, że --tags
została ustawiona. W związku z tym ten specjalny komunikat o błędzie jest teraz nieistotny.
Aby uniknąć pomyłek, usuń ten komunikat o błędzie.
Z Git 2.11+ (IV kwartał 2016) git fetch
jest szybszy.
Zobacz commit 5827a03 (13 października 2016 r.) Autor: Jeff King ( peff
) .
(Połączone przez Junio C Hamano - gitster
- w commit 9fcd144 , 26 paź 2016)
fetch
: użyj „szybkiego” has_sha1_file
do śledzenia tagów
Podczas pobierania ze zdalnego, który ma wiele znaczników, które nie mają znaczenia dla gałęzi, które śledzimy, marnowaliśmy zbyt wiele cykli, sprawdzając, czy obiekt wskazany przez znacznik (którego nie zamierzamy pobrać!) Istnieje w naszym repozytorium zbyt ostrożnie.
Ta łatka uczy Fetch korzystania z HAS_SHA1_QUICK w celu poświęcenia dokładności dla szybkości, w przypadkach, gdy możemy być ryzykowni przy jednoczesnym przepakowaniu.
Oto wyniki z dołączonego skryptu perf, który konfiguruje sytuację podobną do opisanej powyżej:
Test HEAD^ HEAD
----------------------------------------------------------
5550.4: fetch 11.21(10.42+0.78) 0.08(0.04+0.02) -99.3%
Dotyczy to tylko sytuacji, gdy:
- Po stronie klienta masz dużo pakietów, które mogą być
reprepare_packed_git()
drogie (najdroższą częścią jest znalezienie duplikatów na nieposortowanej liście, która jest obecnie kwadratowa).
- Potrzebujesz dużej liczby odnośników do tagów po stronie serwera, które są kandydatami do automatycznego śledzenia (tzn. Których klient nie ma). Każdy wyzwala ponowne odczytanie katalogu paczki.
- W normalnych okolicznościach klient automatycznie śledziłby te tagi i po jednym dużym pobraniu (2) przestałby być prawdziwy.
Ale jeśli te znaczniki wskazują na historię, która jest odłączona od tego, co klient w inny sposób pobierałby, to nigdy nie będzie automatycznie śledzić, a ci kandydaci będą wpływać na nią przy każdym pobieraniu.
Wydaje się, że Git 2.21 (luty 2019 r.) Wprowadził regresję, gdy konfiguracja nieremote.origin.fetch
jest domyślna ( '+refs/heads/*:refs/remotes/origin/*'
)
fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed
Git 2.24 (IV kwartał 2019 r.) Dodaje kolejną optymalizację.
Zobacz commit b7e2d8b (15 września 2019) autor: Masaya Suzuki ( draftcode
) .
(Połączone przez Junio C Hamano - gitster
- w commit 1d8b0df , 07 paź 2019)
fetch
: użyj, oidset
aby zachować pożądane identyfikatory OID w celu szybszego wyszukiwania
W git fetch
tym czasie klient sprawdza, czy identyfikatory OID reklamowanych tagów są już w żądanym ustawieniu OID żądania pobierania.
Ta kontrola jest wykonywana w skanie liniowym.
W przypadku repozytorium, które ma wiele referencji, powtórzenie tego skanowania zajmuje ponad 15 minut.
Aby to przyspieszyć, utwórz oid_set
OID dla innych referencji.