GitLab и LFS отправляют файлы с отсутствующими файлами

У меня есть очень старый репозиторий, который я использовал, и в какой-то момент некоторые файлы LFS пропали. Их довольно много. Когда я пытаюсь нажать на новый репозиторий в Gitlab, я получаю следующую ошибку

 GitLab: LFS objects are missing. Ensure LFS is properly set up or try a manual 

Другой контроль качества для git-lfs (здесь, здесь) указывают, что обычно какой-то вариант git lfs push --all, но у меня нет рабочего репо с этих файлов больше нет, и они ушли навсегда. Gitlab игнорирует отправку с --no-verify и по-прежнему выдает ошибку.

Запуск git lfs fetch --all дает длинный список отсутствующих OID

[43cb9e6d1d15bb8d31af911aa69a15a67174c5df73dabc85294ce08198cac468] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it
[454907d530534af9cc95903820c0a632a851b45de98ba18e1de117b8a649f8ac] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it
[ce1314f0c4cb05f349540fa144d33faeb2281ae552cf75dc866a8350d90fd2ac] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it
[d5e8925d273cb00341f00d0f40b39f97cced1e833ef687de2d4663836e7f4e45] Object does not exist on the server or you don't have permissions to access it: [404] Object does not exist on the server or you don't have permissions to access it
...

Другой пост здесь содержит скрипты для полного удаления LFS путем проверки каждого commit и смазать файлы LFS, но это кажется очень вредным для продвижения репозитория. Еще один указывает путь для полного удаления файла LFS (здесь).

Все эти вопросы кажутся неоптимальными:

  1. Удаление LFS сильно раздует репозиторий, и в любом случае пятно, скорее всего, не удастся для уже поврежденных файлов.
  2. Git pull/push -all не вариант, потому что файлы исчезли навсегда
  3. Удаление LFS неправильно, потому что версия файлов существует сегодня, только объект в какой-то ветке в прошлом отсутствует, поэтому все инструкции по удалению LFS сломают репо.

Есть ли способ заставить GitLab не игнорировать no-verify или эффективно отфильтровывать определенный OID из истории? Я не возражаю, если файлы исчезнут навсегда, но я надеялся сохранить историю.

Я знаю, что могу запустить git log --all -p -S 43cb9e6d1d15bb8d31af911aa69a15a67174c5df73dabc85294ce08198cac468, чтобы получить коммит и файл (хотя запуск PER OID занимает 5-10 минут, так что это займет много часов), но я не знаю, что с этим делать.


person Steve    schedule 23.11.2020    source источник


Ответы (1)


Я только что решил ту же проблему, выполнив следующие шаги:

  • У меня есть относительный путь к грязному файлу git lfs ls-files.
  • Я скачал BFG Repo Cleaner по адресу https://rtyley.github.io/bfg-repo-cleaner/
  • Я запускаю bfg, передавая параметры --delete-files <DIRTY_FILE_PATH>

Журнал BFG сообщил мне следующее предупреждение:

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

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

 * commit 9edf1837 (protected by 'HEAD') - contains 1 dirty file : 
    - requirements/LMD-SE-10-D11/setupse10d11.exe (132 B )

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.

Details of protected dirty content have been recorded here :

<REPO_PATH>/..bfg-report/2021-07-30/14-12-39/protected-dirt/

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 с теми же аргументами.

Наконец, я отдал команды:

git reflog expire --expire=now --all
git gc --prune=now --aggressive

И заставил переписать историю git push --force.

Результат: грязная ссылка LFS наконец исчезла!

person Antonio Petricca    schedule 30.07.2021