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

Ответ 1

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

Точно так же:

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

$ git stash
$ git pull
$ git stash pop

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

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

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

core.trustctime

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

Ответ 7

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

git status ничего не показывал для совершения.

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

Ответ 8

У меня на самом деле такая же проблема. Это всегда происходит, когда я обновляю свое зеркало кода ядра Linux, которое я не изменяю. Выполнение "git stash" позволило продолжить, но теперь я получаю следующее, когда пытаюсь сделать "git stash pop".

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

Когда я выполняю "git status" после pull, я вижу следующее:

linux-2.6:git status
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#   (use "git checkout -- ..." to discard changes in working directory)
#
#   modified:   Documentation/io-mapping.txt
#   modified:   include/linux/netfilter/xt_connmark.h
#   modified:   include/linux/netfilter/xt_dscp.h
#   modified:   include/linux/netfilter/xt_mark.h
#   modified:   include/linux/netfilter/xt_rateest.h
#   modified:   include/linux/netfilter/xt_tcpmss.h
#   modified:   include/linux/netfilter_ipv4/ipt_ecn.h
#   modified:   include/linux/netfilter_ipv4/ipt_ttl.h
#   modified:   include/linux/netfilter_ipv6/ip6t_hl.h
#   modified:   net/ipv4/netfilter/ipt_ecn.c
#   modified:   net/netfilter/xt_connmark.c
#   modified:   net/netfilter/xt_dscp.c
#   modified:   net/netfilter/xt_hl.c
#   modified:   net/netfilter/xt_mark.c
#   modified:   net/netfilter/xt_rateest.c
#   modified:   net/netfilter/xt_tcpmss.c
#
no changes added to commit (use "git add" and/or "git commit -a")

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