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