Подтвердить что ты не робот

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

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

после

git reset --hard

Я получаю

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

git clean -fdx

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

Ответ 2

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

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 .

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

Ответ 3

Это может произойти, когда вы делаете извлечение, содержащее файлы, которые должны были отслеживаться 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:

$

Ответ 4

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

  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 ревизия '... 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 или эта может помочь вам больше, но это то, что сработало для меня.

Ответ 5

  1. Закрыть SourceTree и Visual Studio
  2. Git LFS удалить
  3. Git Rm --cached
  4. git add --force
  5. git lfs install
  6. git lfs pull
  7. git reset --hard

Ответ BheeMa сработал для меня несколько раз, но через некоторое время мне пришлось выполнить описанные выше шаги.

Ответ 6

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

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

>git lfs version
git-lfs/2.7.2

Бежать:

git lfs migrate import --fixup --everything

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

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

Ответ 7

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

  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, настроенных правильным образом.

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

Ответ 8

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

Ответ 9

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

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

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

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

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

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

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

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

Ответ 10

Начиная с 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", чтобы установить сообщение коммита для этого коммита.