Можно ли сказать "git fetch" не использовать "git upload-pack" для локальных репозиториев?

Question

При использовании git fetch для извлечения ссылок из одного (очень большого) хранилища в другое на локальном компьютере, git upload-pack занимает очень много времени для создания файлов пакета. В локальном случае нет такой необходимости минимизировать объем транспортируемых данных, и меня не волнует потеря дискового пространства из-за потери дельта-сжатия, поэтому в идеале я бы предпочел, чтобы отсутствующие объекты были скопированы, а не упакованы, а затем импортирован. Есть ли способ сказать git fetch просто скопировать недостающие объекты при использовании локального транспорта?

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

Между прочим, я потратил некоторое время, пытаясь оптимизировать параметры конфигурации, чтобы перепаковка не заняла так много времени (и не началось перебивание), поэтому я не думаю, что ответ «используйте эти параметры конфигурации, и упаковка будет происходить намного быстрее» "- однако, возможно, я все неправильно понял, так что для ясности, параметры конфигурации, которые я обычно использую (при обработке с 2 ГБ ОЗУ):

core.deltacachesize=1
core.packedgitwindowsize=16m
core.packedgitlimit=128m
pack.packsizelimit=512m
pack.windowmemory=200m
pack.deltacachesize=200m
pack.window=4
pack.compression=3
pack.threads=0
gc.auto=0
gc.pruneexpire=never
receive.autogc=false

Answer 1

Возможно, вы могли бы использовать альтернативный ( хранилище альтернативных объектов ) механизм;это позволило бы обмениваться объектной базой данных с другим локальным хранилищем, а затем не нужно их упаковывать.

Чтобы настроить это, используйте ' git clone ', используя либо опцию --shared, если клонирование из локального репозитория, либо --reference <repository>, если клонирование из удаленного репозитория, но если у вас есть аналогичное хранилище локальноили просто отредактируйте .git/objects/info/alternates файл .

Answer 2

У меня есть хранилище, которое простой старый git clone не будет клонировать:

$ git clone $url
Cloning into foo...
remote: Counting objects: 6142, done.
error: pack-objects died of signal 9839/6058)   
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

Несмотря на то, что он скрывается за текстом прогресса, который перезаписывается, ошибочное сообщение об ошибке: error: pack-objects died of signal 9.

Мне удалось предотвратить ошибку, отключив упаковку на стороне клиента. Я сделал это, выполнив последовательность команд (выпущенных с git 1.7.4.1), которые в основном делают то, что делает git clone, но с дополнительной командой для установки pack.depth в 0 перед запуском git fetch.

mkdir foo
cd foo
git init
git remote add origin $url
git config pack.depth 0
git fetch origin
git branch --set-upstream origin origin/master
git checkout master

Answer 3

Возможно (не проверено) настроить http-backend для вашего первого репо (того, из которого вы берете).

Этот тип сервера имеет настройку, которая может бытьв вашем случае это интересно:

http.uploadpack

Это обслуживает клиентов git fetch-pack и git ls-remote.
Это включено по умолчанию, но хранилище может отключить его, установив для этого элемента конфигурации значениеложь.