git status pełznie na SSHFS przez VPN: przenieś pracę

Skopiuj plik 200 MB i leci. Uruchom git status w tym samym katalogu, a czekanie jest dość długie, by zająć się czymś innym. Te dwa spostrzeżenia nie są sprzeczne, bo transfer masowy mierzy przepustowość, a Git mierzy, ile małych pytań do systemu plików może zadać w sekundzie, i zamontowane zdalne drzewo zamienia każde pytanie w rundę. Strojenie VPN nie naprawi źle uformowanego obciążenia.

Dlaczego status to złe kryterium

Git musi wiedzieć o wielu plikach: które są zmienione, które nieśledzone i czy dane indeksu w pamięci podręcznej nadal zgadzają się z tym, co jest na dysku. Przez SSHFS każde z tych spostrzeżeń może być operacją sieciową. Jednostką pracy jest tu liczba plików, nie megabajty.

Dlatego pierwszy status po klonie jest wolny, i dlatego kolejne mogą być jeszcze wolniejsze w drzewie pełnym wyników kompilacji. Skanowanie nieśledzonych przechodzi przez katalogi, którymi może się nie interesujesz, a każdy krok to kolejne żądanie przez łącze. Na ścieżce 40 ms drzewo z kilkoma tysiącami wpisów staje się kilkoma tysiącami rund. Do potwierdzenia tej arytmetyki nie trzeba przechwytywania pakietów.

Test pobierania mówi, że łącze jest w porządku; nie mówi nic o tym, czy tysiąc małych odczytów skończy się dziś po południu.

Przenieś drzewo robocze, nie pokrętła

Lokalny klon umieszcza drzewo robocze, indeks i operacje Git na tej samej maszynie. Pull staje się widocznym krokiem sieciowym, zamiast być nim przy każdej kontroli pliku.

Pasuje to zawsze, gdy deweloper może trzymać potrzebne źródło lokalnie, a tak jest najczęściej. Wyostrza też granicę między commitem a wdrożeniem, bo edycja lokalnego pliku nie zmienia już przypadkiem działającej usługi zdalnej; zmianę trzeba wypchnąć i wdrożyć jak wszystko inne. Ceną jest to, że kod istnieje w dwóch miejscach, więc zdecyduj, która kopia jest nadrzędna i jak szybka poprawka na serwerze wraca do repozytorium. Ta rozmowa jest tańsza niż polecenie status, którego nikt nie chce uruchamiać.

Jeśli przestrzeń robocza musi zostać zdalna, uruchom tam Git

Czasami przestrzeni roboczej nie da się przenieść: kompilacja potrzebuje tego środowiska, dane są zbyt duże albo polityka trzyma źródło na hoście. Wtedy uruchom Git i odpowiednie narzędzia deweloperskie obok plików, przez zatwierdzoną zdalną powłokę lub środowisko zdalnego rozwoju. Edytor może zostać na laptopie, podczas gdy jego backend pracuje obok drzewa roboczego.

Drogie operacje dzieją się wtedy lokalnie na zdalnym hoście, a sieć przenosi ruch edytora zamiast tysięcy wywołań stat. To ta sama poprawka co lokalny klon, wyrażona jako wybór wdrożenia, a nie migracja.

Synchronizacja to przepływ pracy z właścicielami, nie pamięć podręczna

Zsynchronizowana przestrzeń robocza może ograniczyć powtarzane zdalne odczyty, ale nie jest przezroczystą pamięcią podręczną. Potrzebuje właściciela każdej zmiany, reguły dla konfliktów i uzgodnienia co do generowanych plików, które obie strony uważają za swoje. Bez tych reguł układ tworzy niezgodę, a nie wygodę.

Dwukierunkowy synchronizator bez nich tworzy inny problem niż ten, który rozwiązał, zwykle scalenie, którego nikt nie potrafi przypisać. Unikaj uruchamiania dwóch procesów Git na jednym współdzielonym drzewie roboczym, chyba że rozumiesz, jak się koordynują.

Potem dostrój i utrzymaj SSH w rozsądku

Gdy układ jest właściwy, dwa ustawienia zmieniają, o ile plików Git musi pytać: status.showUntrackedFiles i pamięć podręczna nieśledzonych za core.untrackedCache. Żadne nie zmienia kosztu każdego pytania przez 40 ms; zmieniają tylko liczbę pytań. Pokrętło przekręć dopiero wtedy, gdy rundy są lokalne.

Zmierz czas polecenia, które cię irytuje, zamiast wnioskować z testu kopiującego jeden duży plik, i zostaw obsługiwane szyfrowanie SSH w spokoju. Przestarzały szyfr nie skraca rundy; dokłada drugi problem, który przeżyje pierwszy. Dokumentacja git status jest warta jednej lektury, bo polecenie wykonuje znacznie więcej pracy, niż sugeruje nazwa.