После изменения регистра имени файла, git жалуется на возможную потерю данных при оформлении заказа

Question

На основании этого ответа Я использовал git mv, чтобы изменить регистр расширения имени файла.

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

git checkout MyBranch
error: The following untracked working tree files would be overwritten by checkout:
    MyFile/With/The/OldExtension.Ext
Please move or remove them before you switch branches.
Aborting

Я все еще могу менять ветки с помощью --force, но на самом деле не хочу полагаться на это по понятным причинам.

Мне кажется, что индекс git не синхронизирован с реальностью, но я не уверен, как это исправить.

Какой у меня следующий ход?

Answer 1

TL; DR: вы, вероятно, можете просто удалить файл перед проверкой желаемого коммита.

Предполагая, что вы работаете в системе, в которой происходит смещение регистра с именами файлов, проблема заключается в том, что если Git пытается создать и записать файл с именем readme.txt, когда существует файл с именем README.TXT, это перезапишет существующий README.TXT без создания readme.txt вообще.

Как говорит VonC, если индекс не соответствует действительности, вы можете изменить его. Аналогично, если в индексе нет ничего ценного, вы можете удалить и перестроить его:

rm .git/index
git reset --mixed HEAD

Это делает индекс соответствующим текущему коммиту (а не текущему рабочему дереву!).

Основная проблема здесь заключается в том, что внутреннее устройство Git и индекс Git (поскольку это просто файл данных в .git/index), все работают с необработанными байтовыми строками, которые могут содержать любое имя файла, в том числе и для Экземпляр одновременной readme.txt и README.TXT. Любая система Linux может хранить оба файла в рабочем дереве, ¹ , но обычная файловая система MacOS или Windows не может. В такой ситуации, когда индекс содержит оба файла под этими двумя именами, которые могут существовать одновременно в Linux, но не в вашей собственной системе, индекс гарантированно не соответствует действительности, несмотря ни на что.

В противном случае - если в индексе есть только один вариант регистра - возможно, дело в том, что регистр имени файла вашего рабочего дерева отличается от регистра, сохраненного в индексе, который изначально совпадает с тем, который хранится в коммите, который вы извлекаете. Если / когда базовая ОС подменяет имя файла, которое Git пытается создать при переключении коммитов, Git уверен, что оно создано (скажем) readme.txt и сохраняет это имя в индексе, даже если ОС перезаписала существующий README.TXT и оставила это имя в рабочем дереве.

Параметр core.ignorecase, который Git устанавливает самостоятельно при первом git init хранилище (или когда git clone его инициализирует), записывает, как ОС обрабатывает имена файлов, так что Git будет знать, проверять ли README.TXT существует до того, как Git попытается создать readme.txt. В этом случае вы получите сообщение об ошибке, которое вы видите, потому что Git не уверен, действительно ли README.TXT в рабочем дереве - это readme.txt, который он извлек ранее (возможно, вы удалили и вставьте другой README.TXT, который вы хотите сохранить).

---

¹ Это поведение, зависящее от типа файловой системы, но в файловых системах Linux по умолчанию учитывается регистр. В HFS / HFS + в MacOS вы можете выбрать, во время сборки файловой системы, должна ли файловая система быть чувствительной к регистру. Я верю, что то же самое верно и для NTFS, но я никогда не создавал файловую систему NTFS.

Answer 2

Мне кажется, что индекс git не синхронизирован с реальностью

Затем, как показано здесь, попробуйте тот же git mv в новом клоне репо, чтобы увидеть, не «загрязнен» ли индекс этим невидимым неотслеживаемым файлом.