Git BFG, чтобы задним числом включить проблему с защищенными LFS-коммитами

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

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

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

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

Некоторые из этих защищенных коммитов имели размер более 100,00 МБ и, таким образом, вызывали ошибку remote: из 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.


git github bfg-repo-cleaner
person LearningSlowly    schedule 12.11.2015    source источник

Ответы (1)


arrow_upward
16
arrow_downward

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

Я принял решение по умолчанию предполагать, что проекты были «реформированы» - они делали ошибки в прошлом, но к тому времени, когда пользователь обнаружил BFG, они уже осознали свои ошибки и, по крайней мере, исправили бы свои последние совершает (т.е. они уже совершили бы фиксацию, удалив ненужные данные, в качестве первого шага к решению проблемы). Таким образом, для BFG было безопаснее не изменять последний коммит - альтернативой для BFG было слепое уничтожение всего в истории, включая последнюю версию проекта, и на самом деле программное обеспечение break, которое еще не было готово для чтения паролей из переменных 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.

person Roberto Tyley    schedule 13.11.2015
comment
Отличное объяснение! Спасибо. Проблема решена :) - person LearningSlowly; 13.11.2015