Почему размер репозитория удваивается, когда я копирую заметки?

Я импортирую репозиторий SVN с помощью Subgit, который является отличным инструментом, который делает это быстро и поддерживает пользовательский макет svn. Subgit сохраняет git commit -> ссылку на версию svn в git notes. Каждый коммит имеет номер ревизии в примечаниях, вы можете увидеть его с помощью git log.

После импорта SVN-> git я использую очиститель репозитория BFG для очистки старого репозитория проекта от двоичных файлов, таких как jar, dll и т. д. BFG не перезаписывает ссылки между заметками git и измененными коммитами, но, к счастью, оставляет object-id-map.old-new.txt файла.

Я использую этот файл для копирования заметок из старых коммитов в новые:

cat object-id-map.old-new.txt | git notes copy --stdin

После копирования заметок я удаляю их из старых объектов:

cat object-id-map.old-new.txt | cut -d' ' -f 1 | git notes remove --stdin --ignore-missing

Проблема в том, что после исправления git notes размер репозитория становится в 2 раза больше (даже если я клонирую без --bare). Почему?

Пример: я импортировал репозиторий из svn с помощью Subgit и имею 400 МБ .git. Затем я применяю BFG и получаю голый репозиторий на 40 Мб. Я хочу восстановить заметки git, перемещая (копируя и удаляя) их с помощью двух команд выше, но, к сожалению, размер репо увеличивается с 40 МБ до 80 МБ. Я пытаюсь выполнить git notes prune и git reflog expire --expire=now --all && git gc --prune=now --aggressive, которые рекомендует BFG, но все еще есть 80 Мб.

UPD: сейчас не могу воспроизвести репозиторий размером 40 Мб:/ После очистки BFG 80 и 86 после копирования заметок


git bfg-repo-cleaner subgit git-notes
person Kirill    schedule 05.05.2017    source источник
comment
Возможно это история заметок: git log refs/notes/commits.   -  person user4003407    schedule 05.05.2017
comment
Не могли бы вы попробовать эти 2 команды одну за другой? git -c gc.autoDetach=0 -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc --prune --aggressive и git -c gc.autoDetach=0 -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 -c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now prune   -  person Dmitry Pavlenko    schedule 06.05.2017

Ответы (1)


arrow_upward
1
arrow_downward

Три эволюции в Git (с 2017 года) и инструменты вокруг Git должны помочь с этой проблемой:

  • Первый: такой инструмент, как github/git-sizer, даст вам представление о том, что занимает так много места.
  • Два: git filter-repo (что я упомянутый здесь) теперь заменяет BFG или gilter-branch. Сначала установите его. (python3 -m pip install --user git-filter-repo).
    Это оставит меньше данных после очистки jar/бинарных файлов, которые вам не нужны.
git filter-repo --strip-blobs-bigger-than 10M
  • Третье: объекты, которые потеряли ссылки, могут быть удалены, даже если к ним прикреплены заметки (и эти заметки станут висящими, что, в свою очередь, можно удалить с помощью git notes prune(man)).
    Это разъяснено в документации к Git 2.31 (1 квартал 2021 г.), .

См. commit fa9ab02 (10 февраля 2021 г.) от Мартин фон Цвайгбергк (martinvonz).
(объединено Хунио С. Хамано -- gitster -- в commit d590ae5, 25 февраля 2021 г.)

docs: уточнить, что refs/notes/ не поддерживает прикрепленные объекты

Подписано: Мартин фон Цвейгбергк

git help(man) gc содержит этот фрагмент:

"[...] it will keep [..] objects referenced by the index,
remote-tracking branches, notes saved by git notes under refs/notes/"

Я истолковал это как сообщение о том, что объекты, к которым были прикреплены примечания, сохраняются, но это не так.
Давайте уточним документацию, убрав часть о git notes(man) в отдельное предложение.

git gc теперь включает в свою справочную страницу:

объекты, на которые ссылается индекс, ветки удаленного отслеживания, журналы ссылок (которые могут ссылаться на коммиты в ветках, которые позже были изменены или перемотаны) и все остальное в пространстве имен refs/*.

Обратите внимание, что примечание (типа созданного 'git notes'), прикрепленное к объекту, не способствует сохранению объекта.
Если вы ожидаете, что некоторые объекты будут удалены, а это не так, проверьте все эти местоположения и решить, имеет ли смысл в вашем случае удалить эти ссылки.

person VonC    schedule 27.02.2021