Получение по запросу мерзавца: ошибка: нечто Записи, не актуальное. Не может объединиться

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

Стоит попробовать:

Не могли бы вы установить, только для этого обновления, установить для параметра конфигурации core.trustctime значение false?

core.trustctime

Если false , различия ctime между индексом и рабочей копией игнорируются; полезно, когда время изменения inode регулярно изменяется чем-то вне Git (сканерами файловой системы и некоторыми системами резервного копирования).

Есть несколько способов исправить это, но я обнаружил, что git stash мне подходит. Это временно переносит ваши локальные изменения в другое место. Затем вы можете потянуть, чтобы получить последние изменения. А затем вы можете вернуть свои локальные изменения.

Вот так:

$ git pull
...
...
file your_file.rb not up to date, cannot merge.

$ git stash
$ git pull
$ git stash pop

Такая проблема часто возникает при попытке вытащить из репозитория, в котором есть два имени файлов, различающихся только в случае необходимости. Если вы используете FAT, NTFS в режиме нечувствительности к регистру (по сути, любой раз, когда она используется под Windows) или HFS+ в режиме нечувствительности к регистру, и у вас есть два файла "foobar" и "FOOBAR", то Git увидит два разных файла, но файловая система увидит только один, что вызовет всевозможные проблемы. Git извлечёт, скажем, "FOOBAR", а затем извлечёт "foobar", который файловая система видит как простую замену содержимого "FOOBAR", но оставляет его на месте. Теперь Git'у видит, что "FOOBAR" был заменён на содержимое "foobar", а "foobar" исчез.

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

Другой случай, который вы можете обработать, это когда происходит переименование, которое изменяет регистр файла. Скажем, например, что Git-репозиторий содержит переименование с "EXAMPLE" на "example". Перед тем, как Git проверит новую версию, он попытается проверить, не перезаписывает ли он какой-нибудь существующий файл, имеющийся у вас на диске. Так как он думает, что "example" - это новое имя файла, он спросит файловую систему, существует ли он, и файловая система увидит "EXAMPLE" и скажет "yes", так что Git откажется проверять новую версию, так как он думает, что перезапишет неотслеживаемые файлы. В этом случае, если у вас нет локальных изменений, которые вас волнуют, простого сброса --hard в git'е будет достаточно, чтобы обойти проблему и перейти к новой ревизии. Просто постарайтесь не переименовывать файлы на другие имена, которые отличаются только в том случае, если вы работаете с файловой системой, не чувствительной к регистру, так как это приведёт к таким проблемам.

Это может быть проблема также с правами доступа к файлам. Git также контролирует их версии, если в конфигурации не указано иное. Просто добавляю этот ответ для людей, у которых есть почти такая же проблема, но не такая.