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

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

3 голосов
/ 29 марта 2019

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

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

После выдачи git 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. Как я уже говорил, это не решает проблему, но, по крайней мере, позволяет мне попытаться воссоздать ее или продолжить свою работу и разобраться собъединить позже.

1 Ответ

0 голосов
/ 20 июня 2019

Вам нужно проверить, сохраняется ли проблема в Git 2.23 (Q3 2019), так как данные, собранные fsmonitor, не были должным образом записаны обратно в файл индекса на диске (на Mac, Linuix или Windows)

См. коммит b5a8169 , коммит d4c0a3a (24 мая 2019 г.) от Йоханнес Шинделин (dscho) .
(Объединено с Junio ​​C Hamano - gitster - in commit a3e6b42 , 17 июня 2019 г.)

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

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

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

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

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

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

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

...