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

Как почистить репо, если поставленные файлы помечены как измененные

после

git reset --hard

я получил

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

git clean -fdx

тоже не помогает

Источник

23 ответа

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

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, и она была решена так же, как и при работе с индексом, порождённым строками

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

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

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

Источник

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

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:   Empty/Empty/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:   Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png

$ git lfs status

Git LFS objects to be committed:

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

Git LFS objects not staged for commit:

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

$ git add Empty/Empty/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, любые серверы, файловые обозреватели и браузеры. Иногда этот материал не работает, если он используется где-то еще. Если вы сомневаетесь, остановите это - с этим лучше перебить.

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

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

    В Windows это будет cmd или командное окно. Если вы не уверены, нажмите кнопку Windows и введите cmd, Он предложит командную строку, нажмите на нее.

    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 отслеживает большие файлы, заменяя их указателями. Если вы программист, это похоже на то, как переменная указывает на место в памяти, а не на фактическое значение.

    То, что мы сделали до сих пор,

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

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

    мерзавцы мигрируют

  9. Больше ужасов

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

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

    На странице справки github есть трагический герой @guneyozsan, который разместил эту последнюю часть в головоломке, хотя это не решило его проблему. Он опубликовал это примерно за 2 часа до того, как я начал искать миллионный раз, как это исправить, хотя проблема существует уже 2 года. Благослови вас @guneyozsan, и я желаю вам удачи в решении вашей проблемы.

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

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

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

  10. Копить и тянуть

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

    И бум, ужас окончен. С надеждой. Если нет, то эта страница Git Hub или эта может помочь вам больше, но это то, что сработало для меня.

Источник

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

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

>git lfs version
git-lfs/2.7.2

Бежать:

git lfs migrate import --fixup --everything

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

Нашел в этом комментарии github.

Источник

запустить

      git add --renormalize .

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

Источник

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

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

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

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

Из ответа Рататы Таты в разделе " Как внести изменения в.gitattributes")

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

git rm --cached -r .
sleep 1
git reset --hard
sleep 1
git rm .gitattributes
sleep 1
git reset .
sleep 1
git checkout .
Источник

То же, что и @John Kugelman выше, но я назвал это псевдонимом, потому что мне приходилось делать это много раз.

          
git rm --cached -r . > /dev/null && git reset --hard > /dev/null && git rm .gitattributes > /dev/null && git reset . && git checkout . > /dev/null
Источник

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

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

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

Источник

Следующий процесс добавляет коммит, который заменяет все двоичные файлы, которые должны быть указателями 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"
Источник

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

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

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

сохранил этот .gitattributes, после чего проблем не возникло.

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

Источник

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

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

Решить с помощью git reset --soft: /questions/34810055/skvosh-moj-poslednij-x-kommitov-vmeste-s-pomoschyu-git/34810081#34810081

Источник

Что помогло мне, не касаясь всего репо, так этоgit restoreкоманда, добавленная в git 2.23

git restore --source=HEAD --staged --worktree -- affected_files

Выполните эту команду несколько раз, пока все предупреждения не исчезнут.

Источник

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

      git status -s | cut -c 4- | xargs git update-index --assume-unchanged
rm .git/index && git reset
Источник

Анализ

Это потому, что файлы не отслеживаются LFS, но они соответствуют описанию некоторых файлов .gitattributes.

Например,

сервер/.gitатрибуты:

      conf/** filter=lfs diff=lfs merge=lfs -text
  • server/conf/client.conf слишком велик и отслеживается LFS
  • server/conf/client.gflags отслеживается в git вместо LFS

Однако client.gflags соответствует описанию server/.gitattributes, и git извлечет его из LFS, но у него нет информации LFS, и будет выдана ошибка.

Решение

Найдите файл .gitattributes, описание которого попало в Encoutered file, удалите неправильное описание или оптимизируйте совпадение некоторых подстановочных знаков.

Оптимизируйте пример выше,server/.gitattributes:

      conf/client.conf filter=lfs diff=lfs merge=lfs -text
Источник

В дополнение к ответу кариона после выполнения миграции для исправления локального состояния:

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

У вас есть дополнительная фиксация, от которой вы, вероятно, захотите избавиться.

Учитывая, что .gitattributes уже исправлен в вашей основной / основной ветке, можно просто перебазировать локальную ветку на ту, которая содержит исправление, обычно:

      git rebase upstream/master

И этот дополнительный коммит будет автоматически удален, так как на данный момент он не имеет смысла.

Источник

Вот с этим украшением, которое не требует переустановки хуков lfs или затенения каких-либо.gitattributesфайлы:

      git -c filter.lfs.smudge= -c filter.lfs.clean= reset --hard
Источник

Множество ответов на это с несколькими шагами для исправления.

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

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

Источник

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

  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. Оформить заказ снова на ветке А. Он загрузит предыдущий статус репозитория без надоедливых файлов и настроек LFS, настроенных правильным образом.

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

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