Git LFS - фатальная ошибка разных файлов, отсутствующих на 2 разных машинах

Я переносил свой существующий репозиторий в git lfs, и мне кажется, что каким-то образом мне удалось создать идеальный шторм.

В настоящее время есть две машины: A и B.

На компьютере A отсутствует содержимое файла X. Я получаю сообщение об ошибке при вызове git lfs fetch --all origin, На машине B отсутствует содержимое файла Y.

Я пытаюсь позвонить git lfs push --all origin на обоих. Он не работает на компьютере A, потому что у него нет файла X. Он не работает на компьютере B, потому что у него нет файла Y.

Как я могу решить эту ситуацию? Я понятия не имею, как это произошло или даже могло произойти.

Выход из git lfs push на одной из машин:

Git LFS: (0 of 982 files, 1300 skipped) 0 B / 1.73 GB, 1.09 GB skipped         
d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006 does not 
exist in .git/lfs/objects. Tried 
Assets/weapons/models/at_mine/textures/1k/at_mine__normal_1k.bmp, which 
matches d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006.

Выход из git lfs fetch на одной из машин:

git lfs fetch --all
Scanning for all objects ever referenced...
* 2319 objects found
Fetching objects...
Git LFS: (207 of 207 files, 722 skipped) 524.01 MB / 524.51 MB, 870.82 MB 
skipped
[d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006] Object 
does not exist on the server: [404] Object does not exist on the server
[df1dbb12f35f5392c157beebbc3613f70993c691a68f4cc65033ade528de3418] Object 
does not exist on the server: [404] Object does not exist on the server
[edaf4f6721fb14ce4d38d3adddc86aaaf6fbf0c7db11da451022a4f74af97f30] Object does not exist on the server: [404] Object does not exist on the server
... and so on and so on

Я выполнял миграцию на LFS, используя очиститель репозитория bfg.

** РЕДАКТИРОВАТЬ **

Шаги, которые я выполнил:

  1. Git клон всего репо в его старом виде (от до преобразования) на машину А.
  2. Я запускаю BFG на компьютере A, который, по сути, переписал историю основной ветки (другие ветки не хранились удаленно).
  3. я бегу git push origin master --force как вы должны заменить старую версию мастера новой версией мастера.
  4. я бегу git fetch на машине B, чтобы получить все файлы.
  5. На компьютере B было несколько коммитов в master, которые еще не были отправлены на сервер - потому что они приводили к превышению квоты репо. Поэтому я бегу git rebase --onto origin/master HEAD~3 HEAD перенести неотправленные новые коммиты в новую версию мастера.
  6. я бегу git push origin master на машине Б.

Это то, где я сейчас нахожусь.

Источник

2 ответа

Так что это, вероятно, не связано с состоянием объектов LFS, но может вызвать некоторые проблемы с попыткой очистки. Команда rebase, которую вы показываете для машины B, оставляет вас в несколько неловком состоянии. Если бы вы изначально имели

A --- B --- C --- D <--(master)

а затем вы получили результаты переписать, давая

A --- B --- C --- D <--(master)

A' --- B' <--(origin/master)

указанная вами команда rebase, потому что она указана HEAD как ссылка на ребазинг, поставит вас в отдельное состояние головы с

A --- B --- C --- D <--(master)

A' --- B' <--(origin/master)
        \
         C' --- D' <--(HEAD)

так давить master должен потерпеть неудачу независимо от проблем LFS. Если вы хотите отслеживать D для какой-либо проверки после очистки вы можете пометить ее; а затем с HEAD все еще в D' бежать

git branch -f master

получить

A --- B --- C --- D <--[old-master])

A' --- B' <--(origin/master)
        \
         C' --- D' <--(master)

Но, как я сказал, если на каждой машине отсутствуют некоторые объекты LFS, это не исправит это. Теперь я предполагаю, что обе машины правильно настроены с git-lfs, Я видел довольно странное поведение, если lfs install не был запущен, когда это нужно было; но если вы не делаете что-то непонятное, вряд ли это приведет к тому, где вы находитесь... так что...

Поскольку объекты LFS идентифицируются с помощью SHA-256, два файла с одинаковым идентификатором - это один и тот же файл, что является смехотворно безопасным предположением. Итак, вы можете попробовать найти файл, который отсутствует на компьютере B в .git/lfs/objects на машине A и скопируйте ее вручную. (Или наоборот.) Если между ними у вас есть полный набор объектов LFS, то ситуация может быть исправлена ​​таким образом.

Чтобы найти объект с идентификатором d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006 вы должны посмотреть в .git/lfs/objects/d8/d0/d8d0edd8e03f523ab08de27e72a17272ddd24170764e0a9f836c8ba95cf73006

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

git lfs clean <original.file
Источник

Таким образом, очевидно, вся проблема связана с тем, что я использовал BFG для конвертации своего хранилища. НЕ ДЕЛАЙТЕ ЭТОГО. Насколько я могу судить, это может замуровать ваш репозиторий, как это сделал мой. Используйте git-lfs-migrate.

Первоначально я использовал BFG, потому что было проще понять, как его использовать. Однако это отрицательно сказывается на том, что вы не помещаете.gitattributes в переписанные коммиты, что вызывает всевозможные проблемы, если вы когда-нибудь коснетесь или ответвите что-либо в коммитах, кроме последних. Вы также должны быть очень осторожны, чтобы вручную изменить.gitattributes, чтобы соответствовать команде BFG.

По сути, не используйте BFG для этого, нет никаких причин для этого.

И в первую очередь: создайте резервную копию, прежде чем пытаться переписать историю. И убедитесь, что вы делаете это правильно, потому что вилки на Bitbucket.org и некоторых подобных веб-сайтах не обрабатывают LFS правильно.

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