git status пуже на SSHFS преко VPN-а: преместите посао

Копирајте датотеку од 200 MB и она лети. Покрените git status у истој фасцикли и чекање је довољно дуго да пређете на нешто друго. Та два запажања нису противречна, јер масовни пренос мери пропусност, а Git мери колико малих питања ка систему датотека може да постави у секунди, и монтирано удаљено стабло претвара свако питање у кружно путовање. Подешавање VPN-а неће поправити погрешно обликован посао.

Зашто је status погрешна мера

Git мора да зна за много датотека: које су измењене, које нису праћене и да ли кеширани подаци индекса још одговарају ономе што је на диску. Преко SSHFS свако од тих запажања може бити мрежна операција. Јединица рада овде је број датотека, не мегабајти.

Зато је први status после клонирања спор, и зато следећи могу бити још спорији у стаблу пуном излаза из изградње. Скенирање непраћених пролази кроз фасцикле које вас можда не занимају, и сваки корак је још један захтев преко везе. На путу од 40 ms стабло са неколико хиљада уноса постаје неколико хиљада кружних путовања. Није потребно хватање пакета да би се потврдила та аритметика.

Мера преузимања каже да је веза добра; она не каже ништа о томе да ли ће хиљаду малих читања завршити данас поподне.

Преместите радно стабло, не дугмад за подешавање

Локални клон ставља радно стабло, индекс и Git операције на исти рачунар. Pull постаје видљив мрежни корак уместо да то буде свака провера датотеке.

Ово одговара кад год програмер може да држи потребни извор локално, а то је најчешће. Оно такође заоштрава границу између commit-а и распоређивања, јер уређивање локалне датотеке више не мења случајно удаљену услугу која ради; промена мора да се push-ује и распореди као и све друго. Цена је да код постоји на два места, зато одлучите која копија је меродавна и како хитна поправка на серверу стиже назад у спремиште. Тај разговор је јефтинији од status команде коју нико не жели да покрене.

Ако радни простор мора да остане удаљен, покрените Git тамо

Понекад се радни простор не може преместити: изградњи је потребно то окружење, подаци су превелики или политика држи извор на хосту. Тада покрените Git и одговарајуће алате за развој поред датотека, кроз одобрену удаљену љуску или окружење за удаљени развој. Уређивач може да остане на преносном рачунару док његов backend ради поред радног стабла.

Скупе операције се тада дешавају локално на удаљеном хосту, а мрежа преноси саобраћај уређивача уместо хиљада stat позива. То је иста поправка као локални клон, изражена као избор распоређивања, а не као миграција.

Синхронизација је ток рада са власницима, не кеш

Синхронизовани радни простор може да смањи поновљена удаљена читања, али није прозирни кеш. Потребан му је власник за сваку промену, правило за сукобе и договор о генерисаним датотекама које обе стране сматрају својим. Без тих правила уређење ствара неслагање, а не удобност.

Двосмерни синхронизатор без њих ствара другачији проблем од оног који је решио, обично спајање које нико не може да припише. Избегавајте покретање два Git процеса над једним дељеним радним стаблом, осим ако разумете како се координирају.

Затим подесите и држите SSH разумним

Када је уређење исправно, две поставке мењају о колико датотека Git мора да пита: status.showUntrackedFiles и кеш непраћених иза core.untrackedCache. Ниједна не мења цену сваког питања кроз 40 ms; оне мењају само број питања. Окрените дугме тек када кружна путовања постану локална.

Измерите време команде која вас нервира уместо да закључујете из мере која копира једну велику датотеку, и оставите подржано SSH шифровање на миру. Застарели шифрар не скраћује кружно путовање; додаје други проблем који надживљава први. Референца за git status вреди једног читања, јер команда ради много више него што њено име сугерише.