мерзавца: --prune пустого после использования BFG дубликатов совершает

Question

Я использую bfg удалить некоторые подкаталоги из (клона) репозитория:

java -jar bfg-1.12.12.jar --delete-folders {folder1,folder2,folder3} --no-blob-protection myrepo.git/ 
git reflog expire --expire=now --all && git gc --prune=now --aggressive 

Это работает нормально, но после того, как я использовал BFG у меня есть много пустых коммитов (т. е. совершает приятные сообщения журнала, но без изменений, поскольку они касаются только тех файлов, которые были удалены сейчас).

Итак, как следующий шаг я пытался использовать

git filter-branch --commit-filter 'git_commit_non_empty_tree "$@"' HEAD 

или

git filter-branch --prune-empty --tag-name-filter cat -- --all 

Обе версии не имеют желаемого эффекта (удаление пустых фиксаций).

Вместо того, что я в конечном итоге представляет собой хранилище, где (см скриншот ниже, слева находится перед обрезкой, прямо после):

1. несколько пустых коммиты были удалены
2. наиболее пустые фиксаций остаются
3. непустые фиксаций продублированы в отдельных поездах фиксаций

Любые советы?

Answer 1

Из повторяющейся истории, которую вы видите, кажется вероятным, что попытка выполнить пост-BFG-попытку удалить старую, переписанную историю фиксации завершилась неудачно. Это может произойти по ряду причин, но главное, если myrepo.git не является репозиторией с открытым/зеркальным клоном, как описано в инструкциях BFG.

Что-то сохраняет прежнюю историю перезаписи BFG, которая теперь отображается как дубликат. Возможно или даже вероятно, что эта история хранится в удаленном, например origin, и это также объясняет, почему ваш filter-branch не удаляет все пустые коммиты, которые вы ожидаете.

И, наконец, вам может быть интересен текущий запрос тяги к add the --prune-empty-commits feature to BFG - он работает хорошо и, как и у всех BFG, на несколько порядков быстрее, чем работает filter-branch.