Блог

Главная - Вопросы по программированию - Изменения в моем репозитории git постоянно помечаются как предполагаемые-без изменений

Изменения в моем репозитории git постоянно помечаются как предполагаемые-без изменений

#windows #git

#Windows #git

Вопрос:

Я годами использую git в Windows без каких-либо серьезных проблем. Однако прошло некоторое время, и я считаю, что у меня есть что-то, что не соответствует моим локальным репозиториям git, и время от времени мои измененные файлы помечаются как предполагаемые-без изменений до такой степени, что у меня есть псевдоним, который запускает все мои файлы репозитория и update-index --really-refresh --no-assume-unchanged каждый из них, и я использую его почти перед каждым git status . Но так жить нельзя! : P

Я удалил ConEmu со своего компьютера в надежде, что это может помочь, но не получил никаких результатов (имейте в виду, мне, вероятно, следует перезагрузить свой компьютер раньше). Я сомневаюсь, что VS code имеет к этому какое-либо отношение. Я в недоумении tbh. Есть ли какое-либо значение конфигурации git, которое может вызвать это?

Кто-нибудь сталкивался с подобной проблемой и обнаружил злые силы, которые стоят за этим механизмом Макиавелли? Я хочу назвать это и опозорить по всей вселенной…

Если серьезно, то любая помощь была бы высоко оценена.

Комментарии:

1. Вы говорите, что считаете, что ваши файлы помечены как предполагаемые-без изменений: вы подтвердили это убеждение?

2. В следующий раз, когда у вас возникнет это чувство: запустите git ls-files -v | grep '^[a-z]' перед запуском вашего псевдонима. Файлы, помеченные как «предполагаемые-без изменений», помечаются строчной буквой, когда перечислены с ls-files -v .

3. Другие виновники, которые могут быть связаны с вашими файлами: агенты синхронизации файлов, такие как клиенты для OneDrive, Dropbox, Google Drive, ownCloud… Определенно не стоит помещать .git папку в синхронизированный каталог.

4. @LeGEC спасибо за быстрый ответ — итак, я запустил git ls-files -v | grep '^[a-z]' и получаю список файлов с префиксом h и пробелом ( h some/file/path ). Насколько я понимаю, существует какое-то (агрессивное?) кэширование, которое мне нужно отменить. Есть еще идеи?

5. О, да — и я не работаю в синхронизированном каталоге, хотя это и хорошо — может быть кому-то полезно 😉

Ответ №1:

У меня была похожая проблема, но в Linux. Ответ из OP о конфигурации git не сработал для меня, но заставил меня искать в правильном направлении.

Для параметра конфигурации git core.fsmonitor было установлено значение true (перенесено из моей конфигурации Windows, где это был экспериментальный вариант, который улучшил производительность). В моей системе Linux это приводит к тому, что git практически не обнаруживает изменений файловой системы. Теперь, когда я удалил это, все работает просто отлично.

Надеюсь, это поможет кому-то еще с той же проблемой.

Комментарии:

1. Это звучит действительно тонко! Спасибо за информацию, я уверен, что это кому-то поможет.

Ответ №2:

Из вашего комментария: что-то (какой-то скрипт или какой-то другой процесс) устанавливает assume-unchanged флаг для каждого из ваших файлов.

Вы можете заглянуть в свой .git/hooks каталог (также проверьте git config core.hooksPath , настроен ли у вас пользовательский каталог hooks) или в какой-либо другой скрипт / задачу, который передавал бы все файлы в вашем репозитории.

Если вы действительно понятия не имеете, что может быть причиной этого: используйте grep -e "assume-unchanged" -r . (чтобы попытаться определить скрипт, который будет выполняться update-index --assume-unchanged ), сначала в вашем репозитории, затем в вашем домашнем каталоге, в крайнем случае из / …

Комментарии:

1. Я запускаю ваш grep в попытке что-то найти, дам вам знать. спасибо

2. что ж, к сожалению, я не смог найти никаких следов скрипта с «предполагаемым-без изменений» в его содержимом. Я боюсь, что это может быть где-то в каком-то исполняемом файле или, возможно, в каком-то скрипте, который выполнялся, что доступ grep был отклонен. Странно то, что сейчас это происходит на 2 разных машинах. Может быть комбинация расширений vs pro и vs code или что-то в этом роде … : (

3. Просто проверяю: когда вы запускаете git update-index --no-assume-unchanged some/file в своем терминале, это удаляет бит «предполагать без изменений», верно? (буква статуса ls-files -v должна быть заглавной)

4. В противном случае: проверьте свои расширения в vs / vscode. Голые IDE этого бы не сделали (я сильно сомневаюсь в этом, хотя я не просматривал все параметры в «Team / VCS»).

5. как только я запускаю git update-index —no-assume-unchanged some / file, этот файл выводится из ls-files -v как H some/file ; таким образом, я полагаю, это исключает некоторые проблемы с самим git? Если это так, мне придется выполнить проверку vs / vs code extensions…

Ответ №3:

Хорошо, итак, после возни с vs code, resharper и sublime text (удаление всего, удаление остатков, перезапуск компьютера и так далее) — Ничто не указывало на причину этого странного поведения.

А затем я закомментировал весь свой файл gitconfig — и поведение исчезло. Затем мне не потребовалось времени, чтобы выяснить причину такого поведения, была следующая конфигурация, для которой было установлено значение true:

core.ignoreStat

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