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

Question

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

Я пробовал:

git reset --hard

и я получаю ту же проблему

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

Я также пытался git stash, а затем git pull. Не идти.

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

Answer 1

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

Так же, как это:

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

$ git stash
$ git pull
$ git stash pop

Answer 2

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

Answer 3

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

Answer 4

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

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 

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

git status не показывает ничего для фиксации.

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

Answer 8

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

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

core.trustctime

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