Как Git извлекает изменения из пути UNC?

Question

У меня есть репозиторий Git в общей папке на ПК с Windows, доступ к которому осуществляется по пути UNC, например,

git clone //server/share/MyRepo.git

Когда я получаю изменения из этого репозитория по VPN из дома, git-upload-pack.exe очень долго запускается *1006*. Я понимаю, что сервер (как таковой) не задействован, и на моем локальном ПК запущены все исполняемые файлы.

Имя git-upload-pack.exe подсказывает мне, что мой локальный ПК читает файлы с удаленного общего ресурса, чтобы загрузить их куда-то, но это будет само по себе, что не имеет смысла. Это в свою очередь заставляет меня думать, что fetch далеко не так эффективен, как мог бы быть. Это похоже на то, как локальный компьютер выполняет всю работу по сокращению данных для передачи, но для этого он должен передать все данные.

Может кто-нибудь пролить свет на то, как это работает? Является ли производительность настолько высокой, насколько это возможно, без запуска настоящего Git-сервера через SSH или чего-либо еще на удаленном конце, или файлы передаются туда и обратно без необходимости?

Answer 1

В git 2.1 (август 2014 г.) эта выборка должна быть намного быстрее: старое исправление 2012 года наконец-то интегрируется в git.

См. коммит 76e7c8a от (theoleblond)

compat/poll: спать 1 миллисекунду, чтобы избежать занятого ожидания

SwitchToThread() только отдает оставшуюся часть текущего времени другому потоку в текущем процессе. Так что, если поток, который передает дескриптор файла, который мы опрашиваем, не находится в текущем процессе, мы получаем ожидание занято.

Я немного поиграл с этим. Попробовав несколько более сложных схем, я обнаружил, что лучше всего просто спать 1 миллисекунду между итерациями. Хотя это очень короткое время, оно по-прежнему полностью устраняет состояние ожидания занятости, без ущерба для производительности.

Там код использует SleepEx(1, TRUE) для сна.
См. эту страницу для хорошего обсуждения того, почему это лучше, чем звонить SwitchToThread, что и было использовано ранее:

Обратите внимание, что вызов SleepEx(0, TRUE) не не решает занятое ожидание.

Наиболее поразительным был случай тестирования на общем ресурсе UNC с большим репо на одном процессоре.
Без исправления это заняло 4 минуты 15 секунд, а исправление заняло всего 1: 08 ! Я думаю, это потому, что занятое ожидание git-upload-pack отнимало центральный процессор от процесса git, который выполняет настоящую работу.
В multi-proc время не сильно отличается, но тонны процессорного времени все еще тратятся впустую, что может быть убийцей на сервере, который должен делать кучу других вещей.

Answer 2

Он считает, что это похоже на локальную файловую систему.

Существуют альтернативы git по SSH:

1. HTTP [S] (git-http-backend)
2. Простой git-демон.