git status павольнічае на SSHFS праз VPN: перанясіце працу

Скапіюйце файл на 200 MB — і ўсё ляціць. Запусціце git status у той жа папцы, і чаканне будзе дастаткова доўгім, каб пераключыцца на іншую справу. Гэтыя два назіранні не супярэчаць адно аднаму, бо масавая перадача мерае прапускную здольнасць, а Git мерае, колькі дробных пытанняў да файлавай сістэмы ён можа задаць за секунду, і падключанае аддаленае дрэва ператварае кожнае пытанне ў круг туды-сюды. Наладка VPN не выправіць нагрузку, сфармаваную няправільна.

Чаму status — няправільная мера

Git мусіць даведацца пра шматлікія файлы: якія зменены, якія неадсочваныя і ці ўсё яшчэ супадаюць кэшаваныя даныя індэкса з тым, што ляжыць на дыску. Праз SSHFS кожнае з гэтых назіранняў можа быць сеткавай аперацыяй. Адзінка працы тут — колькасць файлаў, а не мегабайты.

Вось чаму першы status пасля клона павольны і чаму наступныя могуць быць яшчэ павольнейшымі ў дрэве, поўным вынікаў зборкі. Сканаванне неадсочваных праходзіць па каталогах, якія вам могуць быць непатрэбныя, і кожны крок — яшчэ адзін запыт праз канал. На шляху ў 40 ms дрэва з некалькімі тысячамі запісаў ператвараецца ў некалькі тысяч кругоў. Перахопу пакетаў для пацверджання гэтай арыфметыкі не трэба.

Тэст хуткасці спампоўкі кажа, што канал добры; ён нічога не кажа пра тое, ці скончыцца тысяча дробных чытанняў сёння пасля абеду.

Перанясіце працоўнае дрэва, а не ручкі наладкі

Лакальны клон ставіць працоўнае дрэва, індэкс і аперацыі Git на адну машыну. Pull робіцца бачным сеткавым крокам, а не кожная праверка файла.

Гэта падыходзіць заўсёды, калі распрацоўшчык можа трымаць патрэбную крыніцу лакальна, а так бывае ў большасці выпадкаў. Гэта таксама робіць мяжу каміта і разгортвання больш выразнай, бо рэдагаванне лакальнага файла ўжо не змяняе выпадкова працуючы аддалены сэрвіс; змену трэба адправіць і разгарнуць, як і ўсё астатняе. Кампраміс у тым, што код існуе ў двух месцах, таму вырашыце, якая копія галоўная і як хотфікс на серверы вернецца ў рэпазіторый. Гэтая размова таннейшая за каманду status, якую ніхто не хоча запускаць.

Калі працоўная прастора мусіць застацца аддаленай, запускайце Git там

Часам працоўная прастора не можа пераехаць: зборцы патрэбна тое асяроддзе, даныя занадта вялікія або палітыка трымае крыніцу на хасце. Тады запускайце Git і адпаведныя інструменты распрацоўкі побач з файламі праз дазволеную аддаленую абалонку або асяроддзе аддаленай распрацоўкі. Рэдактар можа застацца на ноўтбуку, пакуль яго бэкенд працуе побач з працоўным дрэвам.

Даразлівыя аперацыі тады адбываюцца лакальна на аддаленым хасце, а сетка нясе трафік рэдактара замест тысяч выклікаў stat. Гэта тое ж выпраўленне, што і лакальны клон, выказанае як выбар разгортвання, а не як міграцыя.

Сінхранізацыя — гэта працэс з уладальнікамі, а не кэш

Сінхранізаваная працоўная прастора можа скараціць паўторныя аддаленыя чытанні, але яна не празрысты кэш. Ёй патрэбны ўладальнік кожнай змены, правіла для канфліктаў і дамова пра згенераваныя файлы, якія абодва бакі лічаць сваімі. Без гэтых правілаў уладкаванне стварае разыходжанне, а не зручнасць.

Двухбаковая сінхранізацыя без іх стварае іншую праблему, чым тая, якую вырашыла, звычайна зліццё, якога ніхто не можа прыпісаць. Пазбягайце запуску двух працэсаў Git у адным агульным працоўным дрэве, калі вы не разумееце, як яны ўзгадняюцца.

Пасля наладзьце і трымайце SSH разумным

Калі ўладкаванне правільнае, два параметры змяняюць колькасць файлаў, пра якія Git мусіць пытаць: status.showUntrackedFiles і кэш неадсочваных за core.untrackedCache. Ніводзін не змяняе цаны кожнага пытання праз 40 ms; яны змяняюць толькі колькасць пытанняў. Круціце ручку толькі тады, калі кругі сталі лакальнымі.

Замерце час каманды, якая вас раздражняе, замест таго каб разважаць ад тэсту, які капіюе адзін вялікі файл, і не чапайце падтрыманае шыфраванне SSH. Састарэлы шыфр не скарачае круг туды-сюды; ён дадае другую праблему, якая перажыве першую. Даведка па git status вартая аднаго чытання, бо каманда робіць значна больш працы, чым падказвае яе назва.