Как ускорить git fetch с подключенного сетевого диска

Question

У меня есть голое git-репо на сетевом диске.У меня есть локальное рабочее репо на моей машине, где я делаю свои правки, а затем я делаю push / pull на голое репо на сетевом диске.Моя машина работает под управлением Windows.

Когда я на работе, подключение к сетевому диску происходит быстро, и можно получать / загружать / извлекать всю работу в течение разумного периода времени.

Когда яЯ работаю удаленно, я подключаюсь через VPN, который, очевидно, медленнее.извлекать / толкать / тянуть через VPN на несколько порядков медленнее.Я ищу способ ускорить его.

Я подозреваю, что когда git выполняет такие вещи, как «дельта-сжатие» и т. Д., Что он может тратить пропускную способность, загружая информацию на мой компьютер, сжимая ее,а затем отправив сжатые данные в мой репо.Шаг сжатия имеет смысл, если удаленное git-репо находится на удаленной компьютерной системе, которая может локально вычислить сжатие перед отправкой данных по сети.Однако подключенный сетевой диск - это просто удаленная файловая система, поэтому мне интересно, могу ли я ускорить процесс, пропустив этап сжатия.

1) Git делает то, что, как я думаю, делает?
2) Может ли git отличить репозитории, которые находятся на удаленной компьютерной системе от удаленной файловой системы?
3) Можно ли отключить этапы сжатия для удаленных файловых систем?
4) Это лучший способ выполнитьчто я пытаюсь сделать, или есть лучший подход?

Например:

$ git fetch
remote: Enumerating objects: 10, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (6/6), done.  <-- Is this wasted time/bandwidth?
remote: Total 6 (delta 4), reused 0 (delta 0)
Unpacking objects: 100% (6/6), done.
From <repo>
   5bf23b5..fbc1b90  master     -> origin/master

Answer 1

Я подозреваю, что когда git выполняет такие вещи, как «дельта-сжатие» и т. Д., Он может тратить пропускную способность, загружая информацию на мой компьютер, сжимая ее, а затем отправляя сжатые данные в мое хранилище.Шаг сжатия имеет смысл, если удаленное git-репо находится на удаленной компьютерной системе, которая может локально вычислить сжатие перед отправкой данных по сети.Однако подключенный сетевой диск - это просто удаленная файловая система, поэтому мне интересно, могу ли я ускорить процесс, пропустив этап сжатия.

Ваш анализ здесь верен.Тем не менее, нет другого способа сделать это, кроме как сообщить Git, что файловая система является локальной, используя путь вместо URL-адреса, ориентированного на схему.

То есть:

git clone https://example.com/path/to/repo.git

или:

git clone ssh://user@example.com/path/to/repo.git

идут по сети, но также:

git clone file://path/to/repo.git

Что касается Git, то этот репозиторий находится на другом компьютереполностью, что запускает свой собственный сервер Git.(Под прикрытием Git порождает другого Git, выступающего в роли сервера, так что оба работают на одном компьютере.) Однако:

git clone /path/to/repo.git

говорит Git, что он должен , а не относитесь к другому хранилищу как к другому компьютеру.Вместо этого он может напрямую обращаться к файлам.

Будет ли это действительно много, если будет быстрее, или, в конце концов, медленнее , неясно, но, по крайней мере, вы не потеряете Gitвремя сжатия.Вместо этого вы тратите время на доступ.

Лучшее решение состоит в том, чтобы полностью исключить использование функции сетевого диска: найдите сервер, для которого этот диск действительно является локальным (или, по крайней мере, быстрым длядоступ), и укажите ваш компьютер на этот компьютер.Получите этот компьютер для доступа к хранилищу (быстро), сожмите данные (используя свои ЦП с большими усилиями), отправьте сжатые данные на ваш компьютер по медленной сети, а затем сохраните локальная (не сетевой диск) копия хранилища.Первый клон будет медленным, но после этого протокол сжатия и «иметь / хотеть», который сведет к минимуму передачу данных, будет означать, что вам не нужно отправлять много мегабайт через медленную часть системы.