Git happens! 6 типичных ошибок git и как их исправить / хабр

Skip-worktree bit

Бит пропуска рабочего стола может быть определен в одном (длинном)предложении:При чтении записи,если она помечена как skip-worktree,Git делает вид,что его версия рабочего каталога обновлена,и вместо этого читает версию индекса.

Проще говоря, «чтение» означает проверку существования файла, чтение атрибутов файла или содержимого файла. Версия рабочего каталога может присутствовать или отсутствовать. Если он присутствует, его содержимое может совпадать с версией индекса или нет. Этот бит не влияет на запись, безопасность содержимого по-прежнему остается на первом месте

Обратите внимание, что Git обновить файл рабочего каталога, помеченный как skip-worktree, если это безопасно (т.е. версия рабочего каталога соответствует версии индекса)

Хотя этот бит похож на бит «принять неизменным», его цель отличается от бита «предполагать неизменным». Пропуск-рабочее дерево также имеет приоритет над битом предполагаемого неизмененного, когда оба установлены.

3 ответа

Лучший ответ

Всегда был моей рекомендацией (см. «»).

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

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

Вы также можете спрятать свои файлы через меню инструментов git gui и добавить некоторые параметры к этим инструментам, например, с помощью этого файл конфигурации git. Интересно то, что для каждого инструмента вы можете добавить:

Вы можете увидеть это сообщение в : он удаляет файл index.lock, созданный git-gui при манипулировании индексом. Дополнительную информацию можно найти на странице документации по API lockfile :

Community
23 Май 2017 в 12:02

Я также столкнулся с этим, даже несмотря на то, что моя настройка уже установлена на , а не установлена. Я подозреваю, что виноват параметр конфигурации .

Когда я запустил , на выходе была показана следующая строка:

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

Учитывая, что в нем не прокомментирована только вышеприведенная строка и, кроме того, работа с «автоматическими» преобразованиями с окончанием строки всегда была головной болью, я решил удалить этот файл из своего репо. После этого при постановке тех же файлов больше не выводилось предупреждение / ошибка «Ошибка обновления индекса Git».

Kenny Evitt
26 Сен 2016 в 15:54

TL; DR: Это предупреждение означает, что git может вернуть вам текстовый файл в стиле Windows, несмотря на то, что вы проверили текстовый файл в стиле UNIX.

UNIX и Windows различаются тем, как они сохраняют разрывы строк в текстовых файлах. В Википедии есть

Полученное предупреждение можно воспроизвести, если вы выполните следующие действия в Windows:

Создайте репозиторий git в пустом каталоге
Создайте фиксацию, представляющую начальное пустое состояние репо:
используйте и , чтобы убедиться, что для установлено значение и не установлено (нет вывода). Если это не так, используйте следующие команды, чтобы установить их
Используйте Notepad ++, чтобы записать текстовый файл с именем в формате UNIX. Напишите файл, в котором есть хотя бы один разрыв строки. Вот как вы выбираете окончания строк UNIX:
. Вы получаете предупреждающее сообщение
Зафиксируйте текстовый файл: `git commit -m» добавить файл с окончаниями UNIX «
Теперь посмотрите, как выглядит файл, если вы посмотрите его на дереве. Во-первых, проверьте версию до того, как вы создали файл (вернитесь на 1 коммит). Файл исчезает из рабочего каталога:
Теперь восстановите версию после создания файла

Файл восстановлен. Но откройте его в Notepad ++ и проверьте формат окончания строки в нижней строке состояния Notepad ++:

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

akraf
25 Сен 2018 в 09:22

Монитор файловой системы

Данная функция предназначена для ускорения git-операций для репозиториев с большими рабочими директориями.

Это позволяет git работать вместе с монитором файловой системы (см. Раздел «fsmonitor-watchman» в githooks ), который может сообщить ему, какие файлы были изменены. Это позволяет git избегать использования lstat () каждого файла для поиска измененных файлов.

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

Если вы хотите включить (или отключить) эту функцию, проще использовать конфигурации core.fsmonitor (см. Git-config ), чем использовать параметр для в каждом репозитории, особенно если вы хотите сделать это во всех репозиториях, которые вы используете, потому что вы можете установить переменную конфигурации в вашем только один раз, и она повлияет на все репозитории, которых вы касаетесь.

При переменной конфигурации core.fsmonitor монитор файловой системы добавляется в индекс или удаляется из него при следующем чтении индекса командой. Когда используется , монитор файловой системы немедленно добавляется в индекс или удаляется из него.

Examples

Обновлять и обновлять только уже проверенные файлы:

$ git checkout-index -n -f -a && git update-index --ignore-missing --refresh

На неэффективной файловой системе с установленным

$ git update-index --really-refresh              (1)
$ git update-index --no-assume-unchanged foo.c   (2)
$ git diff --name-only                           (3)
$ edit foo.c
$ git diff --name-only                           (4)
M foo.c
$ git update-index foo.c                         (5)
$ git diff --name-only                           (6)
$ edit foo.c
$ git diff --name-only                           (7)
$ git update-index --no-assume-unchanged foo.c   (8)
$ git diff --name-only                           (9)
M foo.c

заставляет lstat(2)устанавливать «assume unchanged» bit для путей,которые соответствуют индексу.
отметьте путь,который нужно отредактировать.
это делает lstat(2)и находит,что индекс соответствует пути.
это выполняет lstat (2) и обнаруживает, что индекс не соответствует пути.
регистрируя новую версию в наборы индексов «предположим,что бит не изменился».
и предполагается,что она не изменилась.
даже после того,как ты его отредактируешь.
ты можешь рассказать о переменах после того,как они произошли.
Теперь он проверяет с помощью lstat(2)и обнаруживает,что он был изменен.

неотслеживаемый кэш

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

Эта функция работает, записывая mtime каталогов рабочего дерева и затем пропуская чтение каталогов и вызовы stat для файлов в тех каталогах, mtime которых не изменилось. Чтобы это работало, базовая операционная система и файловая система должны изменить поле каталогов, если файлы в каталоге добавляются, изменяются или удаляются.

Вы можете проверить, поддерживает ли файловая система это с помощью параметра . Параметр использовался для неявного выполнения этого теста в старых версиях Git, но теперь это уже не так.

Если вы хотите включить (или отключить) эту функцию, проще использовать конфигурации core.untrackedCache (см. Git-config ), чем использовать параметр для в каждом репозитории, особенно если вы хотите сделать это во всех репозиториях, которые вы используете, потому что вы можете установить для переменной конфигурации значение (или ) в вашем только один раз, и это повлияет на все репозитории, которых вы касаетесь.

При переменной конфигурации core.untrackedCache неотслеживаемый кеш добавляется или удаляется из индекса в следующий раз, когда команда читает индекс; в то время как, когда используется , неотслеживаемый кеш немедленно добавляется в индекс или удаляется из него.

До 2.17 в неотслеживаемом кэше была ошибка,при которой замена каталога на symlink на другой каталог могла привести к тому,что он некорректно отображал файлы,отслеживаемые git’ом,как неотслеживаемые.Смотрите коммит «status:add a fail test showing a core.untrackedCache bug» в git.git.Обходной путь для этого-это (и это может сработать для других не обнаруженных ошибок в будущем):

$ git -c core.untrackedCache=false status

Также было показано,что эта ошибка влияет на случаи замены каталога на файл,когда речь идёт о внутренних структурах неотслеживаемого кэша,но не было сообщено ни об одном случае,когда это приводило к неправильному выводу «git-статуса».

Также бывают случаи, когда существующие индексы, написанные версиями git до 2.17, будут ссылаться на каталоги, которые больше не существуют, что может привести к тому, что многие предупреждения «не удалось открыть каталог» будут напечатаны на «git status». Это новые предупреждения о существующих проблемах, которые ранее игнорировались.

Как и в случае с описанной выше ошибкой, решение заключается в однократном запуске «git status» с , чтобы удалить оставшиеся неверные данные.

Использование —cacheinfo или —info-only

используется для регистрации файла, которого нет в текущем рабочем каталоге. Это полезно для слияния с минимальной оплатой.

Чтобы сделать вид,что у вас есть файл в пути с режимом и sha1,скажем:

$ git update-index --add --cacheinfo <mode>,<sha1>,<path>

используется для регистрации файлов без помещения их в базу данных объектов. Это полезно для репозиториев только со статусом.

И , и ведут себя одинаково: индекс обновляется, а база данных объектов — нет. полезен, когда объект находится в базе данных, но файл недоступен локально. полезно, когда файл доступен, но вы не хотите обновлять базу данных объектов.

Использование -индекс-информации

— это более мощный механизм, который позволяет вводить несколько определений записей из стандартного ввода и разработан специально для скриптов. Он может принимать входные данные трех форматов:

режим SP тип SP sha1 путь табуляции

Этот формат предназначен для помещения вывода в индекс.
режим SP sha1 SP путь табуляции ступени

Этот формат предназначен для помещения этапов более высокого порядка в индексный файл и соответствует выходу .
режим SP sha1 путь табуляции

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

Чтобы поместить в индекс запись более высокого уровня,путь должен быть сначала удален,подавая для пути запись в режиме mode=0,а затем подавая необходимые строки ввода в третьем формате.

Например,начиная с этого индекса:

$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52        frotz

вы можете следующий ввод в —index-info :

$ git update-index --index-info
 0000000000000000000000000000000000000000        frotz
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1        frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2        frotz

Первая строка входного сигнала 0 в качестве режима удаления пути;SHA-1 не имеет значения,пока он хорошо отформатирован.Затем вторая и третья строка передает для этого пути записи стадии 1 и стадии 2.После всего вышесказанного мы бы закончили на этом:

$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1        frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2        frotz

10 ответов

Лучший ответ

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

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

Кроме того, может выполняться одно или несколько из следующих утверждений:

Файл был изменен, но в индексе установлен бит «считать неизменным». Взгляните на вывод . Если первый столбец представляет собой строчную букву, то устанавливается бит «считать неизменным». Это предотвратит отображение любых изменений в . Вы можете отключить бит «считать неизменным», запустив .
Файл был изменен, но в индексе установлен бит skip-worktree. Если первый столбец вывода равен или , то установлен бит ‘skip-worktree’. Вы можете отключить бит ‘skip-worktree’, запустив .
Ваш индекс поврежден. Попробуйте удалить (при необходимости Git создаст его заново).
Проблемы с файловой системой мешают правильной работе . Попробуйте запустить . Если ваш рабочий каталог находится на сетевом диске (NFS, sshfs и т. Д.), Попробуйте переместить репозиторий на локальный диск.

Richard Hansen
15 Июл 2011 в 17:25

Возможно, стороннее приложение обновило ваш файл «» ( в Linux / OS X). Со мной так и случилось. Я установил «Исходное дерево» и заметил, что после этого git не отслеживает новые файлы. Было обнаружено, что «Исходное дерево» изменило файл «gitignore_global.txt» и добавило несколько расширений, чтобы он не отслеживался. Попробуйте найти этот файл и посмотреть, нет ли там расширений файла, которые должны быть там.

MikeMB
15 Сен 2015 в 17:34

Скорее всего, ваш файл игнорирует его.

Позвоните и посмотрите, появится ли ваш файл.

Black
29 Мар 2019 в 08:24

Я создал пакет, заканчивающийся на image.gen, у которого был соответствующий каталог, заканчивающийся на image / gen. И была запись .gitignore, специфичная для Android gen /.

Это приводило к тому, что файл не добавлялся в git / отображался в статусе git.

Проверьте ниже, это помогло мне решить проблему.

Используйте команду для отладки файла gitignore (исключите файлы).

Например:

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

Так что, возможно, игнорируется не расширение вашего файла, а весь каталог.

Возвращаемый формат:

Или используйте следующую команду для печати вашего в папке пользователя и репозитория:

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

См .: , для получения более подробной информации.

Community
23 Май 2017 в 12:26

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

У вас есть правило в .gitignore, которое игнорирует файлы
У вас есть каталог .git в одном из скопированных вами каталогов.

Jani Hartikainen
8 Июл 2011 в 04:28

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

hammar
15 Июл 2011 в 16:05

— Решение для старого дела. Вы можете использовать в терминале, но он длиннее, если установлен , код выше, ему потребуется только для файлов, появляющихся в неотслеживаемом месте.

Jorge Borges
16 Сен 2020 в 21:53

Удаление файла .git / index помогло. Довольно неприятная ошибка, с которой я, кажется, сталкиваюсь, когда клонирую скелетные модули в свой проект zf2.

HappyCoder
5 Авг 2015 в 11:38

Android Repo — Та же проблема, с которой я столкнулся — Исправлено, как показано ниже

Как-то добавил . Теперь после удаления все заработало.

Пожалуйста, проверьте свой .gitignore.

gauravsngarg
6 Май 2018 в 03:03

У меня такая же проблема. Git не показал никаких новых файлов, добавленных в мой проект.

Моя была вызвана следующим: каким-то образом основная папка моего проекта была добавлена в «список игнорирования для конкретного репозитория» (так он называется в SourceTree). Это файл «.gitignore» в корне основной папки моего проекта.

Это сработало после того, как я удалил имя папки в файле «.gitignore».

Diorgo
23 Июл 2016 в 11:15

Использование бита «считать неизменным»

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

Обратите внимание, что установка этого бита в пути не означает, что Git проверит содержимое файла, чтобы узнать, не изменилось ли оно — это заставляет Git пропускать любую проверку и предполагать, что это не так.изменилось. Когда вы вносите изменения в файлы рабочего дерева, вы должны явно сообщить об этом Git, отбросив бит «считать неизменным» до или после их изменения

Чтобы установить бит «считать неизменным», используйте параметр . Чтобы отключить, используйте . Чтобы увидеть, в каких файлах установлен бит «считать неизменным», используйте (см. Git-ls-files ).

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

Обратите внимание, что бит «считать неизменным» не устанавливается, если обнаруживает, что файл рабочего дерева соответствует индексу (используйте , если вы хотите пометить их как «предполагать без изменений»)