Wersja TL; DR: gałąź zdalnego śledzenia origin/masterkiedyś istniała, ale teraz jej nie ma, więc lokalna gałąź sourceśledzi coś, co nie istnieje, co jest w najlepszym przypadku podejrzane - oznacza to, że inna funkcja Git nie jest w stanie nic dla Ciebie zrobić - i Git ostrzega Cię przed tym. Dobrze sobie radziłeś bez funkcji „śledzenia nadrzędnego” działającej zgodnie z przeznaczeniem, więc od Ciebie zależy, czy cokolwiek zmienisz.
Aby zapoznać się z innymi ustawieniami nadrzędnymi, zobacz Dlaczego muszę używać polecenia „git push --set-upstream origin <branch>”?
To ostrzeżenie to nowa rzecz w Git, pojawiająca się jako pierwsza w Git 1.8.5. Uwagi do wydania zawierają tylko jeden krótki punkt na ten temat:
- „git branch -v -v” (i „git status”) nie rozróżnia gałęzi, która nie jest oparta na żadnej innej gałęzi, gałęzi, która jest zsynchronizowana z gałęzią upstream i gałęzi skonfigurowanej z odgałęzieniem upstream gałąź, która już nie istnieje.
Aby opisać, co to znaczy, musisz najpierw wiedzieć o „zdalnych zdalnych lokalizacjach”, „zdalnych gałęziach śledzenia” oraz o tym, jak Git obsługuje „śledzenie nadrzędnych”. ( Gałęzie zdalnego śledzenia to strasznie wadliwy termin - zamiast tego zacząłem używać nazw zdalnego śledzenia , co moim zdaniem jest niewielkim ulepszeniem. Poniżej jednak użyję „gałęzi zdalnego śledzenia”, aby zachować spójność z dokumentacją Gita. )
Każdy „remote” to po prostu nazwa, jak origini octopressw tym przypadku. Ich celem jest rejestrowanie takich rzeczy, jak pełne adresy URL miejsc, z których korzystasz git fetchlub git pullaktualizacje. Gdy używasz 1, Git przechodzi do tego pilota (używając zapisanego adresu URL) i przynosi odpowiedni zestaw aktualizacji. Rejestruje również aktualizacje przy użyciu „gałęzi zdalnego śledzenia”.git fetch remote,
„Gałąź zdalnego śledzenia” (lub nazwa zdalnego śledzenia) to po prostu zapis nazwy gałęzi, tak jak ostatnio widziano na „zdalnym”. Każdy pilot jest sam w sobie repozytorium Git, więc ma gałęzie. Gałęzie na zdalnym „źródle” są zapisywane w lokalnym repozytorium pod remotes/origin/. Tekst, który pokazał mówi, że tam jest oddział nazwany sourcena origin, a gałęzie nazwie 2.1, linklogi tak dalej na octopress.
(„Normalna” lub „lokalna” gałąź to oczywiście tylko nazwa gałęzi, którą utworzyłeś we własnym repozytorium).
Na koniec możesz skonfigurować gałąź (lokalną), aby „śledzić” „gałąź zdalnego śledzenia”. Gdy gałąź lokalna Ljest ustawiona na śledzenie gałęzi ze zdalnym śledzeniem R, Git wywoła Rjej „upstream” i powie ci, czy jesteś „przed” i / lub „za” nadrzędnym (pod względem zatwierdzeń). To normalne (nawet godne polecenia), że lokalny oddział i gałęzie zdalnego śledzenia używają tej samej nazwy (z wyjątkiem zdalnej części prefiksu), jak sourcei origin/source, ale nie jest to w rzeczywistości konieczne.
W tym przypadku tak się nie dzieje. Masz oddział lokalny, który sourceśledzi oddział ze zdalnym śledzeniem origin/master.
Nie musisz znać dokładnej mechaniki, jak Git konfiguruje lokalną gałąź do śledzenia zdalnego, ale są one istotne poniżej, więc pokażę, jak to działa. Zaczynamy od lokalnej nazwy oddziału, source. Istnieją dwa wpisy konfiguracji używające tej nazwy, pisane branch.source.remotei branch.source.merge. Z danych wyjściowych, które pokazałeś, jasno wynika, że oba są ustawione, więc po uruchomieniu podanych poleceń zobaczysz następujące informacje:
$ git config --get branch.source.remote
origin
$ git config --get branch.source.merge
refs/heads/master
Kładzenie to razem, 2 to mówi Git że oddział sourceśledzi „zdalnego śledzenia oddział” origin/master.
Ale teraz spójrz na wynik programu git branch -a, który pokazuje wszystkie nazwy gałęzi śledzenia lokalnego i zdalnego w twoim repozytorium. Nazwy zdalnego śledzenia są wymienione pod remotes/... i nie maremotes/origin/master . Prawdopodobnie był kiedyś, ale teraz go nie ma.
Git informuje Cię, że możesz usunąć informacje o śledzeniu za pomocą --unset-upstream. Spowoduje to usunięcie zarówno branch.source.origini branch.source.merge, jak i zatrzymanie ostrzeżenia.
Wydaje się dość prawdopodobne, że to, czego chcesz, to jednak przejście od śledzenia origin/masterdo śledzenia czegoś innego: prawdopodobnie origin/source, ale może jedna z octopress/nazw.
Można to zrobić z git branch --set-upstream-to, 3 , np:
$ git branch --set-upstream-to=origin/source
(zakładając, że nadal znajdujesz się w „źródle” gałęzi, a to origin/sourcejest żądane źródło - nie ma sposobu, abym mógł stwierdzić, który z nich, jeśli w ogóle, chcesz.
(Zobacz także: Jak zmienić istniejącą ścieżkę gałęzi Git na gałąź zdalną? )
Myślę, że sposób, w jaki tu trafiłeś, jest taki, że kiedy pierwszy raz zrobiłeś coś git clone, z czego sklonowałeś, miało gałąź master. Miałeś również gałąź master, która była ustawiona na śledzenie origin/master(jest to normalna, standardowa konfiguracja dla gita). Oznaczało to, że miałeś branch.master.remotei branch.master.mergeustawiłeś, na origini refs/heads/master. Ale potem twój originpilot zmienił nazwę z masterna source. Wydaje mi się, że zmieniłeś również lokalną nazwę z masterna source. Zmieniło to nazwy twoich ustawień, od branch.master.remotedo branch.source.remotei od branch.master.mergedo branch.source.merge... ale pozostawiło stare wartości , więc branch.source.mergeteraz było błędne.
W tym momencie zepsuło się połączenie „upstream”, ale w wersjach Gita starszych niż 1.8.5 Git nigdy nie zauważył zepsutego ustawienia. Teraz, gdy masz 1.8.5, wskazuje to na to.
To obejmuje większość pytań, ale nie dotyczy pytania „czy muszę to naprawić”. Jest prawdopodobne, że od lat zajmujesz się załamaniem, robiąc (np .). Jeśli będziesz to robić dalej, problem będzie nadal działać - więc nie, nie musisz tego naprawiać. Jeśli chcesz, możesz użyć do usunięcia upstream i zatrzymania skarg, ale nie oznaczaj lokalnego oddziału jako posiadającego w ogóle żadnego upstream.git pull remote branchgit pull origin source--unset-upstreamsource
Celem posiadania upstream jest uczynienie różnych operacji wygodniejszymi. Na przykład, git fetchpo którym następuje git mergegeneralnie „zrobi to, co należy”, jeśli pierwszeństwo jest ustawione poprawnie, a git statuspo nim git fetchpowie Ci, czy twoje repozytorium pasuje do tego głównego dla tej gałęzi.
Jeśli chcesz wygody, zresetuj upstream.
1git pull zastosowań git fetch, a od Git 1.8.4, to (wreszcie!) Aktualizuje również „zdalnego śledzenia oddział” informacji. W starszych wersjach Git, aktualizacje nie nagrane na zdalne śledzenie oddziałów z git pulltylko z git fetch. Ponieważ Twój Git musi być w wersji co najmniej 1.8.5, nie stanowi to dla Ciebie problemu.
2 Cóż, to plus linia konfiguracji, którą celowo ignoruję, a która znajduje się pod remote.origin.fetch. Git musi zmapować nazwę „merge”, aby dowiedzieć się, że pełna nazwa lokalna zdalnego oddziału to refs/remotes/origin/master. Jednak mapowanie prawie zawsze działa właśnie w ten sposób, więc można przewidzieć, że tak mastersię stanie origin/master.
3 Lub za pomocą git config. Jeśli chcesz tylko ustawić nadrzędny kanał origin/sourcena jedyną część, która musi się zmienić, to branch.source.mergei git config branch.source.merge refs/heads/source
zrobiłbyś to. Ale --set-upstream-tomówi, co chcesz zrobić, zamiast zmuszać cię do robienia tego ręcznie, więc to jest „lepszy sposób”.