Git BFG для обратной активации LFS - проблема с защищенными коммитами

У меня есть большие файлы, и я пытался использовать новую систему Git LFS.

Я отправил этот вопрос - Git lfs - "это превышает ограничение размера файла GitHub в 100,00 МБ"

Эдвард Томсон правильно определил мою проблему - вы не можете использовать LFS задним числом. Он предложил мне использовать поддержку BFG LFS

Это работало до определенной степени. Подавляющее большинство моих файлов были изменены. Однако были защищенные коммиты, которые не были изменены.

Некоторые из этих защищенных коммитов имели размер более 100,00 МБ и, таким образом, вызывали удаленное: ошибка из github

Protected commits
-----------------

These are your protected commits, and so their contents will NOT be altered:

 * commit c7cd871b (protected by 'HEAD') - contains 165 dirty files :
    - Directions_api/Applications/LTDS/Cycling/Leisure/l__cyc.csv (147.3 KB)
    - Directions_api/Applications/LTDS/Cycling/Work/w_cyc.csv (434.0 KB)
    - ...

WARNING: The dirty content above may be removed from other commits, but as
the *protected* commits still use it, it will STILL exist in your repository.

If you *really* want this content gone, make a manual commit that removes it,
and then run the BFG on a fresh copy of your repo.

Прежде всего - кто-то может объяснить, почему эти коммиты защищены и отличаются от тех, которые BFG успешно изменил?

Во-вторых, как я могу снять их и разрешить BFG редактировать их, что позволяет мне правильно использовать LFS и, наконец, успешно перенести в GitHub

Источник

1 ответ

Решение

Первоначально BFG был создан как инструмент для уничтожения нежелательных данных (больших файлов, паролей), скрытых глубоко в истории Git. После того, как BFG запустится, данные исчезнут, и программы часто необходимо адаптировать для обработки этих данных, которые больше не являются непосредственно доступными (т. Е. Их необходимо изменить для чтения паролей из переменных среды или для загрузки больших зависимостей). Адаптация программ для обработки этих изменений не является шагом, который можно легко автоматизировать - людям необходимо обновить код, чтобы справиться с этими изменениями!

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

Это поведение можно отключить, добавив --no-blob-protection флаг, например:

$ java -jar ~/bfg-1.12.7.jar --convert-to-git-lfs '*.{exe,dll}' --no-blob-protection

Я планирую обновить BFG, чтобы неявно использовать --no-blob-protection флаг, когда --convert-to-git-lfs является единственной выполняемой операцией - потому что это больше не действительно разрушительная операция.

Полное раскрытие: я являюсь автором BFG Repo-Cleaner.

Источник
Другие вопросы по тегам