Różnice między zdalną aktualizacją git a pobieraniem?

Czy git remote updateto odpowiednik git fetch?

AKTUALIZACJA: więcej informacji!

Powinienem był to zrobić od samego początku: poznałem uwagi do wydania Git w repozytorium Git Git (więc meta!)

grep --color=always -R -C30 fetch Documentation/RelNotes/* | less

Potem zrobiłem lesswyszukiwania --all, a to co znalazłem pod Release Notes Git wersji 1.6.6 :

git fetchnauczył się --alli --multipleopcje, aby uruchomić pobieranie z wielu repozytoriów, a także --pruneopcję usuwania zdalnych gałęzi śledzenia, które stały się nieaktualne. Sprawiają one, git remote updatea git remote prunemniej konieczne (nie ma planu, aby usunąć remote updateani remote prune, choć).

Wersja 1.6.6 została wydana dopiero 23 grudnia 2009 roku , a oryginalny plakat zadał to pytanie 6 grudnia 2009 roku.

Jak widać z informacji o wydaniu, autorzy Git byli świadomi faktu, że git remote updatefunkcjonalność polecenia była w pewnym stopniu powielana git fetch, ale postanowili jej nie usuwać, być może ze względu na wsteczną kompatybilność z istniejącymi skryptami i programami, a może dlatego, że to po prostu za dużo pracy i są przedmioty o wyższym priorytecie.

Oryginalna odpowiedź z dodatkowymi szczegółami

Odpowiedź xenoterracide ma już 3,5 roku, a Git przeszedł przez kilka wersji od tego czasu (od wersji 1.5.5.5 do wersji 1.8.3.2 w tym tekście), i patrząc na aktualną dokumentację git remote updatei git fetchwygląda na jak oni mogą wykonywać zarówno w zasadzie taką samą funkcję pobierania nowych zobowiązuje z wielu pilotów , biorąc pod uwagę odpowiednie opcje i argumenty.

Pobieranie wszystkich pilotów

Jednym ze sposobów pobierania wielu pilotów jest użycie --allflagi:

git fetch --all

Spowoduje to pobranie ze wszystkich skonfigurowanych pilotów, przy założeniu, że ich nie remote.<name>.skipFetchAllustawiłeś:

Jeśli to prawda, ten pilot będzie domyślnie pomijany podczas aktualizacji za pomocą git-fetch (1) lub podkomendy aktualizacji git-remote (1) . - dokumentacja git-config

Byłoby to równoważne z użyciem

git remote update

bez określania grupy zdalnej do pobrania, a także bez remotes.defaultustawiania w konfiguracji repo, a także, że żaden z pilotów nie jest remote.<name>.skipDefaultUpdateustawiony na true.

Prąd 1.8.3.2 Dokumentacja dla konfiguracji git jest nie wspomnieć o remotes.defaultustawienie, ale konsultowany Wszechmogącego Google o nim i uznało tę pomocne wyjaśnienia od Mislav Marohnić :

$ git config remotes.default 'origin mislav staging'
$ git remote update

# fetches remotes "origin", "mislav", and "staging"

Możesz zdefiniować domyślną listę pilotów, które będą pobierane przez remote updatepolecenie. Mogą to być piloty od członków zespołu, zaufanych członków społeczności projektu typu open source lub podobne.

Przypuszczalnie więc, jeśli remotes.defaultustawiłeś, a nie wszystkie piloty są w nim wymienione, to git remote updatenie pobierze wszystkich pilotów, o których Twoje repozytorium jest „świadome”.

Jeśli chodzi o remote.<name>.skipDefaultUpdateustawienie, doktorzy Git wyjaśniają to w następujący sposób:

Jeśli to prawda, ten pilot będzie domyślnie pomijany podczas aktualizacji za pomocą git-fetch (1) lub podkomendy aktualizacji git-remote (1) .

Pobieranie określonej grupy pilotów

Zamiast pobierania wszystkich pilotów, zarówno fetchi remote updatepozwalają na określenie wielu pilotów i grupy pilotów, aby pobrać:

git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…]

git fetch [<options>] <group>pozwala pobrać wiele pilotów należących do grupy (pożyczyć inny przykład od Mislava ):

$ git config remotes.mygroup 'remote1 remote2 ...'
$ git fetch mygroup

git fetch --multiplepozwala określić kilka repozytoriów i grup repozytoriów do pobrania jednocześnie (z dokumentów ):

Pozostawić kilka <repository>i <group>argumenty, które zostaną określone. Nie <refspec>smożna określić.

Niejednoznaczność w git remote updatedokumentacji

Podsumowanie dlagit remote update określa, że ​​składnia polecenia jest następująca:

git remote [-v | --verbose] update [-p | --prune] [(<group> | <remote>)…]

Zwróć uwagę na ostatnią część [(<group> | <remote>)…]? Końcowe kropki ...oznaczają, że możesz określić wiele grup i pilotów za pomocą polecenia, co oznaczałoby, że zachowuje się on tak samo jak git fetch --multiple... widzisz, jak składnia między nimi jest taka podobna?

Jednak w tym samym dokumencie wyjaśnienie updatepolecenia nie mówi nic o określaniu wielu argumentów grupowych i zdalnych, tylko tyle

Pobierz aktualizacje [es] dla nazwanego zestawu pilotów w repozytorium zdefiniowanym przez remotes.<group>.

Nie jest więc jasne, czy git remote updatedziała identycznie git fetch --multiplew odniesieniu do określania wielu pojedynczych pilotów i wielu zdalnych grup.

Pobieranie pojedynczego pilota

Wreszcie, wszyscy znają prosty przypadek pobrania jednego pilota:

git fetch <remote>

Może być tak, że możesz także użyć

git remote update <remote>

aby zrobić to samo, ale jak wspomniałem w poprzedniej sekcji, dokumentacja dla git remote updatenie jest jasna, czy możliwe jest pobranie czegoś innego niż pojedyncza grupa pilotów za pomocą polecenia.

Zakończyć

Jak już wyjaśniono, git fetchi git remote updatezachowują się podobnie w odniesieniu do pobierania z wielu pilotów. Dzielą one podobną składnię i argumenty, choć git fetchsą krótsze, więc ludzie prawdopodobnie łatwiej je pisać i używać.

Może być tak, że git remote updatenie można użyć do pobrania tylko jednego pilota git fetch, ale jak wskazałem, dokumentacja nie wyjaśnia tego.

Na bok

Powielanie funkcjonalności między poleceniami porcelany Git, zilustrowanymi przez git fetchi git remote updatepowyżej, nie jest wyjątkowe. Zauważyłem podobną sytuację git rebase --ontoi git cherry-pick, że oba mogą podjąć szereg zobowiązuje się do plastra do nowej bazy popełnił.

Wydaje mi się, że ponieważ Git ewoluował przez lata, niektóre funkcje zostały (nieuchronnie?) Zduplikowane, być może czasem dla wygody użytkowników końcowych (na przykład łatwiej jest przekazać zakres cherry-pick, niż przekazywać pojedyncze zatwierdzenie w kółko wybrać zakres). Najwyraźniej cherry-picknie zawsze akceptował zakres zatwierdzeń, jak wyjaśniono w informacjach o wersji v1.7.2 :

git cherry-picknauczył się wybierać zakres zatwierdzeń (np. cherry-pick A..Bi cherry-pick --stdin), podobnie jak git revert; nie obsługują one jednak lepszej kontroli sekwencjonowania rebase [-i].

Tak i nie. git remote updatepobiera ze wszystkich pilotów, nie tylko jednego.

Nie patrząc na kod, aby sprawdzić, czy remote updatejest tylko skryptem powłoki (możliwe), w zasadzie uruchamia pobieranie dla każdego pilota. git fetchmoże być znacznie bardziej szczegółowy.