Git pull: ошибка: запись foo не обновлена. Невозможно объединить

Я пытаюсь обновить свое репо из удаленной ветки и продолжаю получать эту ошибку, когда выполняю «git pull». Я не делал никаких локальных изменений, и даже если они есть, мне не нужно их сохранять.

Я пытался:

git reset --hard

и у меня такая же проблема

Единственное, что, похоже, работает, - это удалить файл с ошибкой и снова попробовать git pull.

Я также пробовал git stashследовать за файлом git pull. Нет.

edit: используя PortableGit-1.6.4-preview20090729, поэтому все предыдущие ошибки с ложными ошибками должны быть исправлены.

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

Именно так:

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

$ git stash
$ git pull
$ git stash pop

Это может произойти, если вы обновите индекс, чтобы игнорировать определенные файлы:

git update-index --assume-unchanged <file>

а затем, например, проверить другую ветку:

git checkout <branch>
> error: Entry '<file>' not uptodate. Cannot merge.

Принудительное обновление индекса устраняет проблему:

git update-index --really-refresh
<file>: needs update

С последующим:

git reset --hard 

И тогда все должно вернуться на круги своя.

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

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

Другой случай, который можно обойти, - это когда происходит переименование, которое меняет регистр файла. Скажем, например, что репозиторий Git содержит переименование с «ПРИМЕР» на «пример». Прежде чем Git проверит новую версию, он попытается проверить, не перезаписывает ли он какой-либо существующий файл, который у вас есть на вашем диске. Поскольку он думает, что «example» - это новое имя файла, он спросит файловую систему, существует ли оно, и файловая система увидит «EXAMPLE» и скажет «да», поэтому Git откажется проверять новую версию, так как считает, что она будет перезаписана. неотслеживаемые файлы. В этом случае, если у вас нет локальных изменений, которые вас интересуют, простойgit reset --hard <revision-to-checkout>обычно будет достаточно, чтобы решить проблему и перейти к новой версии. Просто постарайтесь не переименовывать файлы на другие имена, которые отличаются только в том случае, если вы используете файловую систему без учета регистра, так как это вызовет подобные проблемы.

Чтобы подробнее рассказать о сообщении @Brian Campbell (поскольку жесткий сброс тоже не сработал), я хочу указать на крайний случай, который меня останавливал.

Я переместил файл OldFileв другую папку и переименовал его NewFile. Затем я пометил файл как assume-unchanged.

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

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

У меня была аналогичная проблема (Windows 10): я был включен branchAи хотел перейти на master. У меня были некоторые незавершенные изменения, поэтому сначала я git stashтогда, git checkout -f masterно я все еще получил Entry 'fileName' not uptodate. Cannot merge.

git status не показывал, что нужно совершать.

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

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

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

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

core.trustctime

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

Добавляю свой ответ, потому что никто из других не упоминает об этом. В моем случае это произошло после того, как я добавил новые файлы в индекс с -Nфлагом, поэтому просто добавляю их в индекс без добавления их содержимого. В этом состоянии выполнение git stashприводит к этой ошибке.

У меня была такая же ошибка после ситуации, когда git statusсказано, new file: foo.cppчто файл не добавлен в область подготовки. то есть под заголовком «Изменения, не предназначенные для фиксации». Очень странно, обычно этого не происходит.

Решение:, git add foo.cppа потом git stashснова работало.