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

Я прочитал каждый пост здесь о похожих проблемах, но ни один из них не похож на мой.

В моем случае, я сделал простое изменение одной строки в одном из моих файлов и хотел зафиксировать свои изменения, но заметил, что commit -am "" не добавил / зафиксировал файл.

После выдачи мерзавца ls-files --stageЯ вижу, вероятно, все файлы в моем проекте отображаются как дубликаты. Вот пример одного из файлов

100644 6314bd3f89d1b794c6d8c0fb9bb4aa492e2d510a 0   SquirrelFoH/Squirrel.FoH.ViewModels/UserLoginViewModel.cs
100644 6314bd3f89d1b794c6d8c0fb9bb4aa492e2d510a 0   SquirrelFoH/Squirrel.FoH.ViewModels/UserLoginViewModel.cs

Интересно, что некоторые из файлов, показывающих дубликаты рекламы, не были изменены мной вообще, некоторые - но, тем не менее, они отображаются как дубликаты, и, как вы можете видеть ниже, регистр не является проблемой, как в других постах SO здесь.

ОБНОВИТЬ

Хотя это не решает мою проблему, описанную выше, это помогло мне использовать git reset --hard HEAD~1 который сбрасывает указатель HEAD на 2-й последний коммит, который является коммитом, который сработал. я использую --hard выше, чтобы отменить последний коммит, так как это вызвало проблему для меня выше. Если вам нужно сохранить эти изменения, используя --soft вместо этого сбросит HEAD на ваш коммит перед последним коммитом и добавит изменения последнего коммита в промежуточную область.

git reset --hard HEAD~1
git reset --hard HEAD~2
git reset --hard HEAD~3
...

Вышеупомянутые команды сбрасывают указатель HEAD 1, 2, 3, ... фиксирует до последнего коммита и отменяет любые изменения после. использование --soft вместо --hard если вы не хотите отменить эти изменения, в этом случае эти изменения будут подготовлены для вас.

Это ситуация, которая у меня была. Ниже, последний коммит - это коммит А, который содержит дубликаты, которые начали появляться после последнего изменения удаленных изменений в моей локальной ветке. Коммиты B, C,... являются коммитами перед коммитом A:

commit A
commit B - git reseat --hard HEAD~1
commit C

Теперь мой последний коммит - коммит B, в котором нет дубликатов. Теперь я могу попытаться снова объединиться и посмотреть, возникнет ли у меня та же проблема, что и с коммитом A. Как я уже говорил, это не решает проблему, но, по крайней мере, позволяет мне попытаться воссоздать ее или продолжить свою работу и разобраться с слить позже.

Источник

0 ответов

Вам нужно будет проверить, сохраняется ли проблема в Git 2.22.1 (3 квартал 2019 г.)/ Git 2.25 (1 квартал 2020 г.), поскольку данные, собранные fsmonitor не был должным образом записан обратно в индексный файл на диске (в Mac, Linux или Windows)

См. Commit b5a8169, commit d4c0a3a (24 мая 2019 г.) Йоханнес Шинделин (dscho).
(Слияние Junio ​​C Hamano -gitster- в коммите 10432cc, 25 июля 2019 г.)

mark_fsmonitor_valid(): пометьте индекс как измененный, если необходимо

Без этого исправления ошибки четыре тестовых примера t7519 "статус не обнаруживает незарегистрированные модификации" иногда терпели неудачу (и, как ни странно, гораздо чаще в Windows).

Причина в том, что в этих тестовых примерах намеренно используется побочный эффект git status чтобы перезаписать индекс, если были обнаружены какие-либо обновления: сначала они очищают рабочее дерево, запускают git status чтобы обновить индекс, а также показать вывод обычному читателю, затем снова сделать рабочее дерево грязным и ожидать, что никаких изменений не будет сообщаться, если он выполняется с имитацией ловушки fsmonitor.

Проблема с этой стратегией заключалась в том, что индекс был написан во время указанного git statusна чистом рабочем дереве по неправильной причине: не потому, что индекс был помечен как измененный (это не так), а потому, что записанныйmtimes были колоритны с собственным временем индекса.

Как mtimeстепень детализации в Windows составляет 100 наносекунд (см., например, https://docs.microsoft.com/en-us/windows/desktop/SysInfo/file-times),mtimesфайлов достаточно часто не соответствует индексу ', так чтоgit status вызов в настоящее время не всегда обновляет индекс (включая fsmonitor extension), что приведет к сбою тестового примера.

Очевидное исправление: если мы изменим любую запись индексаCE_FSMONITOR_VALID флаг, мы также должны отметить индекс как измененный.
Это приведет к тому, что индекс будет записан наgit status, в том числе обновленныйfsmonitor расширение.

Боковое примечание: даже если читатель может подумать, что проблема t7519 должна быть намного более распространенной в Linux, учитывая, что файловая система ext4 (которая, похоже, используется каждым дистрибутивом Linux) хранит mtimes с точностью до наносекунды. Однако ext4 используетcurrent_kernel_time()(см. https://unix.stackexchange.com/questions/11599; невероятно трудно найти какой-либо надлежащий источник информации по таким вопросам ext4), точность которых, кажется, зависит от многих факторов, но безопасно хуже, чем 100- наносекундная гранулярность NTFS (опять же, ужасно трудно найти что-либо хоть сколько-нибудь авторитетное по этому вопросу). Таким образом, похоже, что условие индекса racy, которое скрывает ошибку, исправленную этим патчем, просто намного более вероятно в Linux, чем в Windows. Но не невозможно;-)

В Git 2.25 (первый квартал 2020 г.) fsmonitor стал более надежным и удаляет некорректный BUG(), который не должен запускаться.

См. Commit 61eea52 (13 ноября 2019 г.), автор: Junio ​​C Hamano (gitster).
(Слияние Junio ​​C Hamano -gitster- в коммите aec3b2e, 01 декабря 2019 г.)

fsmonitor: не сравнивать размер растрового изображения с размером разделенного индекса

Докладчик: Утсав Шах.
Помощник: Кевин Уилфорд.
Помощник: Уильям Бейкер.

3444ec2e ("fsmonitor: не заполнять растровое изображение удаляемыми записями ", 2019-10-11, Git v2.24.0-rc1 - слияние указано в пакете № 11) добавлено несколько проверок работоспособности, которые гарантируют, что битовая позиция в битовой карте fsmonitor не выходит за пределы индекса.

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

За исключением случая, когда мы находимся в режиме разделенного индекса и смотрим на дельта-индекс, который должен быть наложен на базовый индекс, но до фактического объединения базового индекса, а именно в read_ и write_fsmonitor_extension().

В этих кодовых путях записи в индексе разделения / дельты обычно представляют собой небольшое подмножество всего набора путей (иначе зачем нам использовать разделенный индекс?), Поэтому растровое изображение, используемое fsmonitor почти всегда больше, чем количество записей в частичном индексе, и некорректное сравнение вызовет ошибку BUG().

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