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 варта одного читання, бо команда робить набагато більше, ніж підказує її назва.