Git pull: error: wpis foo not uptodate. Nie można scalić

Próbuję zaktualizować repozytorium ze zdalnego oddziału i nadal otrzymuję ten błąd, gdy wykonuję polecenie „git pull”. Nie wprowadziłem żadnych lokalnych zmian, a nawet jeśli tak, nie muszę ich zachowywać.

Próbowałem:

git reset --hard

i mam ten sam problem

Jedyną rzeczą, która wydaje się działać, jest usunięcie pliku powodującego problem i ponowne wykonanie polecenia git pull.

Próbowałem również, git stasha następnie git pull. Nie idź.

edit: używając PortableGit-1.6.4-preview20090729, więc wszelkie poprzednie błędy z fałszywymi błędami powinny zostać naprawione.

Jest kilka sposobów, aby to naprawić, ale znalazłem git stash dobrze dla mnie. Tymczasowo umieszcza lokalne zmiany w innym miejscu. Następnie możesz pociągnąć, aby pobrać najnowsze zmiany. A potem możesz odzyskać lokalne zmiany.

Takie jak to:

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

$ git stash
$ git pull
$ git stash pop

Może się tak zdarzyć, jeśli zaktualizujesz indeks, aby zignorować określone pliki:

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

a następnie na przykład do kasy w innej branży:

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

Wymuszenie odświeżania indeksu rozwiązuje problem:

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

Śledzony przez:

git reset --hard 

A potem wszystko powinno wrócić do normy.

Ten rodzaj problemu jest często spowodowany próbą ściągnięcia z repozytorium, które ma dwie nazwy plików różniące się tylko wielkością liter. Jeśli korzystasz z FAT, NTFS w trybie bez rozróżniania wielkości liter (zasadniczo za każdym razem, gdy jest używany w systemie Windows) lub HFS + w trybie bez rozróżniania wielkości liter i masz dwa pliki „foobar” i „FOOBAR”, Git zobaczy dwa różne pliki, ale system plików zobaczy tylko jeden, co spowoduje różnego rodzaju problemy. Git pobierze, powiedzmy „FOOBAR”, a następnie wyewidencjonuje „foobar”, który system plików widzi jako po prostu zastępujący zawartość „FOOBAR”, ale pozostawiający go na miejscu. Teraz dla Gita wygląda na to, że „FOOBAR” został zastąpiony zawartością „foobar”, a „foobar” zniknął.

Istnieją dwa różne przejawy tego podstawowego problemu. Po pierwsze, repozytorium faktycznie zawiera dwa pliki, które różnią się tylko wielkością liter. W takim przypadku musisz pracować na systemie plików uwzględniającym wielkość liter lub będziesz musiał edytować repozytorium, aby upewnić się, że nie wystąpią tego rodzaju kolizje; system plików bez rozróżniania wielkości liter po prostu nie może przechowywać zawartości tego repozytorium.

Innym przypadkiem, który można obejść, jest zmiana nazwy, która zmienia wielkość liter w pliku. Załóżmy na przykład, że repozytorium Git zawiera zmienioną nazwę z „EXAMPLE” na „example”. Zanim Git sprawdzi nową wersję, spróbuje sprawdzić, czy nie nadpisuje istniejącego pliku, który masz na dysku. Ponieważ uważa, że ​​„przykład” jest nową nazwą pliku, zapyta system plików, czy istnieje, a system plików zobaczy „PRZYKŁAD” i powie „tak”, więc Git odmówi pobrania nowej wersji, ponieważ uważa, że ​​zostanie nadpisana nieśledzone pliki. W takim przypadku, jeśli nie masz żadnych lokalnych zmian, na których Ci zależy, prosty plikgit reset --hard <revision-to-checkout>generalnie wystarczy, aby przejść przez problem i przejść do nowej wersji. Po prostu spróbuj i pamiętaj, aby nie zmieniać nazw plików na inne nazwy, które różnią się tylko w przypadku, gdy jesteś w systemie plików bez rozróżniania wielkości liter, ponieważ spowoduje to takie problemy.

W celu dalszego rozwinięcia postu @Brian Campbell (ponieważ reset ciężki też nie zadziałał), chcę wskazać krytyczny przypadek, który mnie powstrzymywał.

Przeniosłem plik OldFiledo innego folderu i zmieniłem jego nazwę NewFile. Następnie oznaczyłem plik jako assume-unchanged.

To uniemożliwiało mi zmianę gałęzi i nie było skrytki do zapisania lub zobowiązania do pchania. Problem polegał na tym, że nie zatwierdziłem tej zmiany pliku z nową nazwą przed ustawieniem assume-unchangedflagi. Ustawiłem więc z powrotem na no-assume-unchanged, zatwierdziłem, a następnie ustawiłem z powrotem na assume-unchangedi mogłem ponownie zmienić gałęzie.

Ogólnie rzecz biorąc, oznacza to, że masz zmiany w swoich plikach lokalnych, które nie zostały zatwierdzone do lokalnego repozytorium. Możesz również zobaczyć to pytanie o przepełnienie stosu, aby uzyskać nieco więcej szczegółów.

Widziałem podobny problem (Windows 10): byłem włączony branchAi chciałem przejść do master. Miałem pewne uncommited zmian więc najpierw git stashwtedy git checkout -f masterale ja wciąż mam Entry 'fileName' not uptodate. Cannot merge.

git status nie pokazywał nic do popełnienia.

W końcu po prostu usunąłem plik ręcznie i mogłem przejść do innej gałęzi (co oczywiście spowodowało powrót mojego pliku), więc myślę, że gdzieś w git pojawił się błąd.

Może to być również problem z uprawnieniami do plików. Git również je wersjonuje, chyba że config mówi inaczej. Po prostu dodaję tę odpowiedź dla osób, które mają prawie podobny problem, ale nie podobny.

Warte spróbowania:

Czy możesz ustawić, tylko dla tej aktualizacji, parametr configcore.trustctime na false?

core.trustctime

Jeśli false, różnice w ctime między indeksem a kopią roboczą są ignorowane; przydatne, gdy czas zmiany i-węzła jest regularnie modyfikowany przez coś poza Gitem (przeszukiwacze systemu plików i niektóre systemy zapasowe).

Dodając moją odpowiedź, ponieważ nikt z innych o tym nie wspomina. W moim przypadku stało się to po dodaniu nowych plików do indeksu z -Nflagą, a więc po prostu dodanie ich do indeksu bez dodawania ich zawartości. W tym stanie działanie git stashpowoduje ten błąd.

Miałem ten sam błąd po sytuacji, w której git statuspowiedziano, new file: foo.cppże plik nie został dodany do obszaru przemieszczania. tj. pod nagłówkiem „Zmiany nie zostały wprowadzone do zatwierdzenia”. Bardzo dziwne, to zwykle się nie zdarza.

Rozwiązanie:, git add foo.cppa następnie git stashdziałało ponownie.