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

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

git clone //server/share/MyRepo.git

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

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

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

Источник

2 ответа

Решение

В 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 время не сильно отличается, но тонны процессорного времени все еще тратятся впустую, что может быть убийцей на сервере, который должен делать кучу других вещей.

Источник

Он думает, что это как локальная файловая система.

Есть альтернативы git по SSH:

  1. HTTP [S] (git-http-backend)
  2. Обычный мерзавец-демон.
Источник
Другие вопросы по тегам