Обновление: git prune
"решит" проблему, поскольку удалит эти незакрепленные объекты
(git gc
вызывает git prune
, но по умолчанию только для незакрепленных объектов старше двух недель).
Однако, как ОП Майкл Донохью упоминает в комментариях:
Мне нравится аспект безопасности - держать незакрепленные предметы в течение двух недель, если я захочу вернуться и посмотреть на некоторые старые ревизии, поэтому мне не очень нравится это решение.
У меня нет проблем с размером или производительностью git, просто «git gui» настаивает на том, чтобы попросить меня сжать базу данных, даже если сжатие базы данных не будет иметь никакого эффекта.
Оригинальный ответ:
Проблема "git gc
" не удаляет все незакрепленных объектов, о которых сообщалось ранее (в конце 2008 г. "" git gc
", кажется, больше не удалял незакрепленные объекты"
git gc
удаляет только незакрепленные объекты старше двух недель, если вы действительно хотите удалить их сейчас, запустите git prune.
Но убедитесь, что никакой другой процесс git не может быть активным, когда вы запускаете его, иначе он может
на что-то.
"git gc
" будет распаковывать объекты, которые стали недоступны и в настоящее время находятся в упаковках.
В результате объем дискового пространства, используемого репозиторием git, может на самом деле резко увеличиться на вверх после операции "git gc
", что может удивить кого-то, кто работает почти полностью на своей файловой системе, удаляет несколько веток из репозитория отслеживания, а затем «git gc
» может получить очень неприятный сюрприз.
[
Пример: ]
Старые ветви резервируются с помощью тега, такого как next-20081204
.
Если вы обновляете локальную копию репозитория linux-next
каждый день, вы накопите большое количество этих старых тегов ветвления.
Если затем удалить целую серию из них и запустить git-gc
, операция займет довольно много времени, а количество используемых блоков и инодов значительно возрастет.
Они исчезнут после "git prune
", но когда я делаю эту вспомогательную операцию, я часто желаю --yes-I-know-what-I-am-doing-and-it's-unsafe-but-just-drop-the-unreachable-objects-cause-this-is-just-a-tracking-repository
вариант "git gc".
Итак, в вашем случае "1059 *" было бы полезно?
(возможно, с использованием "now" в переменной конфигурации gc.pruneexpire
, необходимой для того, чтобы вышеописанное поведение имело место).
У вас также есть (из той же темы):
repack -a -d -l
Обратите внимание на строчную букву 'a'.
git-gc
вызывает repack с прописной буквой «A», что приводит к распаковке недоступных объектов. Маленькая буква «а» предназначена для людей, которые знают, что делают, и хотят, чтобы git просто сбрасывал недоступные объекты.