Git pull: помилка: Запис foo не оновлений. Неможливо об’єднати

Я намагаюся оновити своє репо з віддаленої гілки і продовжувати отримувати цю помилку, коли роблю "git pull". Я не вносив жодних локальних змін, і навіть якщо мав, мені не потрібно їх зберігати.

Я пробував:

git reset --hard

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

Єдине, що, здається, працює - це видалення файлу-порушника та повторна спроба git pull.

Я також пробував, git stashза яким слідує a git pull. Не ходити.

редагувати: за допомогою 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 перевірить нову версію, він спробує перевірити, чи не перезаписує якийсь наявний файл, який є на вашому диску. Оскільки він вважає, що "приклад" - це нове ім'я файлу, він запитає у файлової системи, чи існує вона, і файлова система побачить "ПРИКЛАД" і скаже "так", тому 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 також встановлює версії для них, якщо конфігурація не говорить інше. Просто додавши цю відповідь для людей, які мають майже, але не подібну проблему.

Варто спробувати:

Не могли б ви встановити, лише для цього оновлення, встановити параметр configcore.trustctime на false?

core.trustctime

Якщо значення false, різниці в ctime між індексом та робочою копією ігноруються; корисно, коли час зміни inode регулярно змінюється чимось за межами Git (сканери файлової системи та деякі системи резервного копіювання).

Додаю свою відповідь, бо ніхто з інших про це не згадує. У моєму випадку це сталося після того, як я додав нові файли до індексу з -Nпрапором, тому просто додавши їх до індексу, не додаючи їх вмісту. У такому стані виконання git stashдає цю помилку.

У мене була та ж помилка, після ситуації, коли git statusсказано, new file: foo.cppщо файл не доданий до області проходження. тобто під заголовком "Зміни не запроваджені для коміту". Дуже дивно, цього зазвичай не буває.

Рішення:, git add foo.cppа потім git stashзнову працював.