Почему "обновление индекса Git не удалось" отображается

Я использую Windows. При размещении файлов я получаю эту ошибку.

Updating the Git index failed. A rescan will be automatically started to resynchronize git-gui.

затем следует список файлов, которые были преобразованы из LF в CRLF

после Большого чтения проблемы CRLF / LF с кросс-платформой использования Git я более или менее понимаю, что происходит, и я пытаюсь определить, какая настройка autocrlf лучше для меня, но я не могу понять, почему Git говорит, что обновление индекса не удалось. Насколько я понимаю, она преобразовал EOF, так в чем проблема с этим и почему он говорит мне, что обновление индекса не удалось. Нужно ли мне что-то исправить ( кроме выбора соответствующей настройки autocrlf) или я могу просто продолжить

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

43
core.autocrlf git newline windows

3 ответов

git config --global core.autocrlf false

всегда была моей рекомендации (см. "git 1.6.4 beta на Windows (msysgit) - Unix или DOS прекращение строки").

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

core.safecrlf

если true, git проверяет, является ли преобразование CRLF обратимым при активном преобразовании конца строки. Git проверит, изменяет ли команда файл в дерево работы прямо или косвенно. Например, фиксация файла с последующей проверкой того же файла должна привести к исходному файлу в дереве работы. Если это не относится к текущему параметру core.autocrlf, git отклонит файл.
Переменная может быть установлена в "warn", в этом случае git будет предупреждать только о необратимом преобразовании, но продолжит операцию.

если вы не хотите видеть эти предупреждения, как описано в этот нить, вы можете установить core.safecrlf до false.

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

guitool.<name>.norescan

не сканируйте рабочий каталог на наличие изменений после завершения выполнения инструмента.

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

вы можете увидеть это сообщение в index.tcl скрипт Git-gui: он удаляет индекс.файл блокировки Git-gui создается при манипулировании индексом.
Вы можете увидеть больше на "файл API в разделе" Документация:

взаимоисключение.
Когда мы пишем новый индексный файл, сначала мы создаем новый файл $GIT_DIR/index.lock, запишите в него новое содержимое и переименуйте его в окончательный пунктом $GIT_DIR/index.
Мы пытаемся создать С O_EXCL чтобы мы могли заметить и потерпеть неудачу, когда кто-то другой уже пытается обновить индексный файл.

44

Я также столкнулся с этим даже tho мой core.autocrlf настройки уже false и core.safecrlf не установлено. Я подозреваю, что виновником является настройка конфигурации diff.astextplain.textconv.

когда я подбежал git config --list, на выходе была показана следующая строка:

diff.astextplain.textconv=astextplain

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

* text=auto

[Я, вероятно, получил .gitattributes по файл из GitHub.]

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

1

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

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

предупреждение, которое вы получаете, воспроизводимо, если вы сделаете следующее В Windows:

  • создайте репозиторий git в пустом каталог

  • создайте фиксацию, представляющую начальное пустое состояние РЕПО:

    git commit --allow-empty -m "initial commit"

  • использовать git config core.autocrlf и git config core.safecrlf чтобы проверить, что autocrlf установлено значение true и safecrlf не установлен (без вывода). Если это не так, используйте следующие команды, чтобы установить их в

    git config core.autocrlf true
git config --unset core.safecrlf

  • использовать Блокнот++ написать текстовый файл с именем text.txt в формате UNIX. Написать файл, содержащий хотя бы одну строку ломать. Вот как вы выбираете окончание строки UNIX: Notepad++ with the menu Edit - EOL Conversion opened

  • git add text.txt. Вы получаете предупреждение

    предупреждение: LF будет заменен на CRLF в тексте.формат txt.
    Файл будет иметь исходные окончания строк в вашем рабочем каталоге.

  • зафиксировать текстовый файл: 'git commit-m" добавить файл с окончаниями UNIX"

  • теперь посмотрите, как выглядит файл например, если посмотреть с дерева. Во-первых, проверьте версию перед созданием файла (go 1 commit back). Файл text.txt исчезает из рабочего каталога:

    git checkout ~1

  • теперь восстановите версию после создания файла

    git checkout master

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

The restored file which has now Windows-style CRLF endings

файл, который вы проверили, имеет окончание строки в стиле Windows, но файл, который вы отправили, имел окончание файла в стиле UNIX! Вот о чем предупреждает сообщение:параметры core.autocrlf=true вместе с core.safecrlf=<unset> означает, что файлы, которые вы восстанавливаете из дерева, могут отличаться от файлов, которые вы зарегистрировали, потому что они могут иметь разные окончания файлов.

0