Ошибка Git: обнаружено 7 файлов, которые должны были быть указателями, но не были

Как и Трэвис Хитер, упомянутый в его ответе, попробуйте следующую последовательность команд:

git lfs uninstall
git reset --hard
git lfs install
git lfs pull

В случае, если это не сработает (потому что это не сработало для меня), может сработать следующий хак:

git rm --cached -r .
git reset --hard
git rm .gitattributes
git reset .
git checkout .

Это сработало для меня!

У меня была эта точная ошибка с некоторыми файлами, хранящимися с помощью git-LFS и решил это так же, как я решил индексирование borked, вызванное линизацией.

Очистите кеш и выполните полный сброс:

git rm --cached -r .
git reset --hard

Для меня это было значительно быстрее, чем новый клон, из-за огромных файлов git-LFS в моем репо.

Начиная с git lfs 2.5.0, доступна новая команда, которая упрощает эту задачу (docs):

git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...

Это «переносит» файлы в git lfs, которые должны находиться в lfs согласно .gitattributes, но их нет в данный момент (что является причиной вашего сообщения об ошибке).

--no-rewrite не позволяет git применять это к более старым коммитам, вместо этого он создает одну новую фиксацию.

Используйте -m "commitmessage", чтобы установить сообщение о фиксации для этой фиксации.

Проблема возникает из-за несоответствия между типами файлов, отмеченными как отслеживаемые git LFS в .gitattributes, и некоторыми совпадающими файлами, уже находящимися под обычным контролем версий, отличным от LFS.

Итак, самый простой обходной путь здесь - просто на мгновение удалить файл .gitattributes:

git rm .gitattributes
git reset .
git checkout .

После этого вы можете оформить заказ в любом другом филиале.

Еще один совет: при добавлении нового типа файла в git LFS предпочитайте не делать это вручную, изменяя .gitattributes, но, например, запустив:

git lfs track PATTERN

где ШАБЛОН - это шаблон для сопоставления файлов, например *.so

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

Это может произойти, когда вы выполняете проверку, содержащую файлы, которые должны были отслеживаться LFS, как указано в .gitattributes, но каким-то образом они были зафиксированы напрямую. Скорее всего, у вас есть другая программа, управляющая вашим репозиторием, такая как git GUI или IDE.

Это может расстраивать, потому что эти файлы появляются из ниоткуда и мешают вам совершать покупки. Как только вы отложите свои изменения, они вернутся! Если вы застряли в этой ситуации, быстрое решение - зафиксировать эти изменения во временной ветке, чтобы вы могли снова оформить заказ.

Чтобы действительно решить эту проблему, убедитесь, что вы зафиксировали файлы как указатели LFS. Это должно быть так же просто, как использовать git add. Перед фиксацией проверьте свою работу с помощью git lfs status. git lfs ls-files покажет, какими файлами управляет LFS.

git lfs status вводит в заблуждение, поскольку он читает Git LFS objects to be committed, когда действительно перечисляет все изменения. Файлы, которые вы ожидаете отслеживать с помощью LFS, должны читать что-то вроде (LFS: c9e4f4a) или (Git: c9e4f4a -> LFS: c9e4f4a), а не (Git: c9e4f4a).

В качестве примера я обнаружил, что это проблема при добавлении ресурсов изображения через Xcode 9.2, где я добавил «CalendarChecked.png», который он добавил автоматически:

$ git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

$ git lfs status

Git LFS objects to be committed:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (Git: c9e4f4a)

Git LFS objects not staged for commit:

    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (File: c9e4f4a)

$ git add Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png`
$ git lfs status

Git LFS objects to be committed:

    Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (LFS: c9e4f4a)

Git LFS objects not staged for commit:

$

Ни одно из этих решений не помогло мне, но я собрал по кусочкам несколько источников, чтобы наконец все это исправить.

1. Отправьте любые изменения, которые вы не хотите потерять

   Если можете ... Если нет или если вас не волнуют ваши изменения, продолжайте.

2. Остановить все

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

   Кроме того, войдите в диспетчер задач, принудительно завершите все bash.exe процессы. Git Bash имеет тенденцию держать файлы открытыми после закрытия окна.

3. Откройте командное окно (или терминал)

   cd в ваше местное репо.

4. Удалить lfs

   > git lfs uninstall

   Тогда он скажет что-то вроде:

   Hooks for this repository have been removed.
   Global Git LFS configuration has been removed.
   

5. Сброс

   > git reset --hard

   Вероятно, будет много вывода ...

6. Переустановите lfs

   > git lfs install

   Это снова может означать, что он нашел файлы, которые должны были быть указателями, но не были. Ничего страшного, продолжайте!

7. Потяните с lfs

   > git lfs pull

   Надеюсь, использование lfs перезапишет заблокированные файлы.

   Некоторые из моих источников сказали, что на данный момент их репо снова работает, но не я лично. Вы можете открыть SourceTree или что-то еще, чтобы проверить, если хотите, но вам, возможно, придется начать сверху, если это не сработает.

8. Перенести

   Основная проблема здесь в том, что lfs вместо загрузки больших файлов, таких как аудио, видео, изображения - размером более 1 МБ - он просто указывает на них на сервере. Это полезно, если у вас есть куча больших файлов, вы не выгружаете все это. Таким образом, ваше местное репо меньше и шустрее. Однако в силу обстоятельств, в которых я не уверен, кажется возможным повредить указатели. Я уверен, что это проблема, о которой специалисты по lfs знают и над ней работают, но пока мы должны решить ее сами.

   На данный момент мы уже сделали

   • uninstall lfs
   • удалить все
   • переустановить lfs
   • тянуть все

   Итак, теперь у нас есть все эти вещи в нашей папке, которые являются либо файлами, либо указателями на файлы, и lfs необходимо выяснить, должны ли какие-либо файлы быть указателями и наоборот. И, надеюсь, выполнив описанные выше шаги, мы удалили поврежденные указатели. Итак, мы собираемся выполнить migrate, чтобы запустить процедуру, которая просматривает файлы в репо, и если они больше 1 МБ, lfs заменит их указателем.

   > git lfs migrate

9. Еще ошибки

   Вот момент, когда другие остановились и сказали, что снова работают, но не я. У меня ошибка:

   Ошибка в git rev-list ... статус выхода 128 фатальный: неправильная версия '..._ 17_'

   @guneyozsan на странице справки github, опубликовал это последний кусок головоломки, хотя это не решило его проблемы.

   > git lfs migrate info --include-ref=v1.0.0

   Обратите внимание, что версия соответствует версии с ошибкой - v1.0.0. Вам нужно будет заменить v1.0.0 той версией, которая указана в вашей ошибке.

   Я не нашел источника, почему возникает эта ошибка, но я предполагаю, что номер версии lfs, сгенерированный migrate в вашем локальном репо, не соответствует исходной версии. Для меня все это началось, когда SourceTree разбился во время push, и я принудительно перезагрузил машину, и когда это происходит, lfs не знает, как с этим справиться, поэтому он просто застревает в этом цикле, где пытается обновить, но он не может прочитать поврежденные данные. Отсюда и длительный поиск неисправностей.

10. Спрятать и вытащить

Когда вы откроете SourceTree, вы, вероятно, увидите, что он хочет вернуть все ваши файлы. Не делай этого. Спрятать, а затем вытащить.

И бум, мы надеемся, что ужас закончился. Если нет, то эта страница центра git или этот может вам больше помочь, но у меня это сработало.

Убедитесь, что у вас установлена ​​git lfs версия 2.5 или выше (загрузите здесь).

Убедитесь, что вы используете git lfs версию, которую вы скачали (2.7.7 для меня):

>git lfs version
git-lfs/2.7.2

Бегать:

git lfs migrate import --fixup --everything

Вытяните свою ветку и исправьте любые конфликты слияния.

Найдено в этом комментарии github.

Одна из возможных причин этой ошибки - из-за изменений .gitattributes, связанных с git LFS, которые влияют на уже добавленные файлы в репо.

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

В этом случае я выполнил следующие шаги: чтобы эта ошибка не повторялась повторно.

1. Исправьте проблему для ветки, в которой вы находитесь, следуя одному из других ответов здесь (например, чтобы очистить кеш и выполнить сброс. Я нашел ответ BheeMa, чтобы быть эффективным.)
2. Перейдите в свою основную ветку и убедитесь, что нечего фиксировать с помощью git status
3. Заставить git перепроверить и "повторно применить" изменения атрибутов git

Из ответа Рататы Тата в Как чтобы изменения в .gitattributes вступили в силу)

 git rm --cached -r .
 git add -A

Предупреждение: на шаге 2 убедитесь, что фиксировать нечего, так как указанные выше шаги добавят все файлы, для которых ранее не было версий

4. Проверьте результаты с помощью git status (он должен был изменить только соответствующие файлы, чтобы они стали указателями LFS, т. Е. Файлы, которые потенциально могут вызвать ошибку «обнаруженные файлы, которые должны были быть указателями») и зафиксировать изменения.
5. (При желании объедините / переустановите это исправление для всех других веток, если это возможно. В противном случае эта ошибка может появиться снова при переключении на эти ветки. Обратите внимание, что может потребоваться повторить первоначальное исправление для каждой ветки в соответствии с шагом 1, чтобы быть в безопасности. , хотя можно было бы просто зафиксировать затронутые файлы.)

Это просто еще раз показывает, что такое куча собачьих **** GIT-LFS.

Вы можете попасть в такую ​​ситуацию, если:

1. Файл содержится в common-base-branch, а не в LFS
2. В ветке lfs-branch на основе common-base-branch файл был перемещен в LFS
3. В другой ветке non-lfs-branch, также основанной на common-base-branch, файл был изменен.

Или альтернативно:

1. Этот файл НЕ содержится в common-base-branch
2. В ветке lfs-branch на основе common-base-branch файл добавлен в LFS
3. В другой ветке non-lfs-branch, также основанной на common-base-branch, файл был добавлен (но не в LFS.

В обоих случаях, когда вы пытаетесь объединить non-lfs-branch в lfs-branch, вы получаете такую ​​ошибку.

Вы можете спросить, почему это вообще должно происходить, но ответ заключается в том, что многие программы разрабатываются более чем одним человеком (именно поэтому у вас в первую очередь есть системы контроля версий, такие как GIT), а люди этого не делают. t всегда общаются друг с другом, или LFS вводится позже в истории проекта в ветке функций, в то время как нормальная разработка все еще продолжается в других ветвях.

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

Что вы хотите сделать сейчас, так это убедиться, что правильная версия конфликтующих файлов попадает в GIT-LFS, поэтому вы можете выбрать ответ на этот вопрос, который делает именно это ... (TODO: Вставьте ссылку хотя бы на один ответ, который работает)

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

1. Полностью очистите рабочую копию. Вместе с приведенным ниже принудительным добавлением это предотвращает добавление или удаление любых файлов из-за шаблонов .gitignore.

   git clean -dfx
   git reset --hard
   git checkout -- .
   

2. Добавьте удаление всего в область подготовки. Рабочую копию трогать не будем.

   git rm --cached -r .
   

3. Снова прочитал все файлы из рабочей копии. Это в основном отменит предыдущую команду, но приведет к переоценке фильтров lfs. Используйте -f, чтобы игнорировать .gitignore. Все имеющиеся файлы были ранее зарегистрированы и должны быть добавлены снова.

   git add -f .
   

4. Промежуточная область теперь должна содержать только двоичные файлы, которые ранее вызывали ошибку «должны были быть указатели».

   git commit -m "moved files to lfs"
   

Если вы просто хотите уйти от этой плохой фиксации, вы можете вернуться к мастеру,

git reset --soft origin/master
git reset --hard

Тогда вы свободны от 7 неприятных файлов, не относящихся к LFS :-)

Вот проблема, с которой я столкнулся:

Допустим, вы создали ветку и каким-то образом зафиксировали файлы как файлы, отличные от LFS. Итак, вы попытались исправить это, позже зафиксировав версию файлов LFS в той же ветке. Однако теперь вы не можете перебазировать или сжать, потому что вы продолжите сталкиваться с этими «файлами, которые должны были быть указателями, но не были» ошибкой в ​​середине перебазирования.

Решите, используя git reset --soft: https://stackoverflow.com/a/5201642/2516916

Когда очевидно, что ошибка возникает из ниоткуда, мы в нашей команде делаем вот что:

1. Отключите lfs для этого конкретного типа файла (изменив .gitattributes или через меню SourceTree)

2. Изменение исчезнет, ​​и вместо этого вы увидите изменение в .gitattributes.

3. Устраните проблему:

   3.1 Одно из решений - выполнить git reset --hard. Другой способ - отменить изменения. Иногда файл не появляется снова.

   3.2.1 Если предыдущее решение не работает, повторите шаги 1 и 2. Затем убедитесь, что эта ветка, в которой вы находитесь (A), уже зафиксировала и отправила все, кроме этих надоедливых файлов. Затем зафиксируйте свое изменение, но не продвигайте его.

   3.2.2: Перейти в другую ветку (B)

   3.2.3: Удалите ту локальную ветвь (A), в которой вы выполнили фиксацию в .gitattributes, принудительно удалив, даже если он говорит, что есть фиксация, которая не была отправлена. Он забудет этот коммит (впоследствии его можно удалить через GC или что-то еще, но это не имеет большого значения, если файл с ошибкой небольшой)

   3.2.4: Снова проверьте ветку A. Он загрузит предыдущий статус репозитория без надоедливых файлов, и настройки LFS будут настроены правильно.

Это всегда работает!

Принятый ответ сработал для меня, но он сработал бы только тогда, когда я вручную набирал команды, я ставил паузы между каждой командой, и теперь он работает как сценарий bash:

git rm --cached -r .
sleep 1
git reset --hard
sleep 1
git rm .gitattributes
sleep 1
git reset .
sleep 1
git checkout .

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

git status -s | cut -c 4- | xargs git update-index --assume-unchanged
rm .git/index && git reset

В моем случае это был один файл по правилам lfs (я предполагаю, что он был зарегистрирован без установленного lfs или чего-то еще).

Итак, я нашел его расширение в файле .gitattributes и прокомментировал эту строку как

#*.7z filter=lfs diff=lfs merge=lfs -text

сохранил этот .gitattributes, после чего git status не обнаружил проблем.

После этого я раскомментировал эту строку (удалил #), сохранил .gitattributes, и git status по-прежнему не показывает никаких проблем.

бегать

git add --renormalize .

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