Я думаю, что есть несколько проблем с этим вопросом: git count-objects
на самом деле не представляет размер хранилища (даже git count-object -v
не совсем); если вы используете что-либо, кроме тупого транспорта HTTP,
новый пакет будет создан для вашего клона, когда вы его сделаете; и (как указал VonC
все, что вы делаете для анализа удаленного репо, не будет учитывать
рабочий размер копии.
Как говорится, если они используют тупой http-транспорт (например, github,
это не так), вы могли бы написать сценарий оболочки, который использовал curl для запроса размеров всех
предметы и пакеты. Это может приблизить вас, но это делает больше http
запросы, которые вам нужно будет сделать еще раз, чтобы действительно сделать клон.
Можно выяснить, что git-fetch
отправит по проводам (на
умный http транспорт) и отправить это для анализа результатов, но это не совсем
хорошая вещь, чтобы сделать. По сути, вы просите целевой сервер упаковать
результаты, которые вы просто собираетесь скачать и выбросить, чтобы вы могли
загрузите их снова, чтобы сохранить их.
Для этого можно использовать что-то вроде этих шагов:
url=https://github.com/gitster/git.git
git ls-remote $url |
grep '[[:space:]]\(HEAD\|refs/heads/master\|refs/tags\)' |
grep -v '\^{}$' | awk '{print "0032want " $1}' > binarydata
echo 00000009done >> binarydata
curl -s -X POST --data-binary @binarydata \
-H "Content-Type: application/x-git-upload-pack-request" \
-H "Accept-Encoding: deflate, gzip" \
-H "Accept: application/x-git-upload-pack-result" \
-A "git/1.7.9" $url/git-upload-pack | wc -c
В конце всего этого удаленный сервер будет упакован в master / HEAD и
все теги для вас, и вы будете загружать весь файл пакета только для
посмотрите, насколько он будет велик, когда вы загрузите его во время клона.
Когда вы наконец сделаете клон, будет создана и рабочая копия, поэтому
весь каталог будет больше, чем эти команды выплевывать, но файл пакета
обычно это самая большая часть рабочей копии с какой-либо значительной историей.