Git pull: erreur: Entrée foo pas à jour. Impossible de fusionner

Question

Je suis en train de mettre à jour mon repo à partir d'une branche distante et reçois ce message d'erreur lorsque je fais un "git pull". Je n'ai pas fait tous les changements locaux, et même si je l'ai je n'ai pas besoin de les garder.

J'ai essayé:

git reset --hard

et j'ai le même problème

La seule chose qui semble fonctionner est de supprimer le fichier avi et essayer un git pull à nouveau.

J'ai aussi essayé de "git stash" suivi par un "git pull". Sans aller.

edit: à l'aide de PortableGit-1.6.4-preview20090729 de sorte que toute précédente bugs avec de faux messages d'erreur doit être corrigée.

Answer 1

Il ya un couple de façons de résoudre ce problème, mais j'ai trouvé git stash fonctionne bien pour moi. Il temporaire met vos changements locaux dans un autre endroit. Ensuite, vous pouvez tirer, pour saisir les modifications les plus récentes. Et puis vous pouvez obtenir vos modifications locales de retour.

Juste comme ça:

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

$ git stash
$ git pull
$ git stash pop

Answer 2

Ce genre de problème est souvent causé par essayer de tirer à partir d'un référentiel qui a deux noms qui diffèrent seulement dans des cas. Si vous êtes sur FAT, NTFS en cas insensibles à la mode (en gros, tout le temps, il est utilisé sous Windows), ou HFS+ en cas insensibles à la mode, et ont deux fichiers "foobar" et "FOOBAR", puis Git verrez deux fichiers différents, mais le système de fichiers ne verrez qu'une seule, ce qui va provoquer toutes sortes de problèmes. Git va checkout, disons, "FOOBAR", puis la commande "foobar", le système de fichiers voit que le simple fait de remplacer le contenu de "BLABLA" mais en le laissant en place. Maintenant, Git, il semble que le "FOOBAR" a été remplacé par le contenu de "foobar", et "foobar" a disparu.

Il y a deux différentes manifestations de ce problème de base. On est quand votre dépôt contient en fait deux fichiers qui ne diffèrent que sur des cas. Dans ce cas, vous avez besoin de travailler sur la casse du système de fichiers, ou vous aurez besoin de modifier le référentiel afin de s'assurer que pas de collisions de ce type se produisent; la casse du système de fichiers ne peut tout simplement pas stocker le contenu de ce référentiel.

Une autre affaire que vous pouvez contourner le problème est lors de l'une de renommer arrive que des modifications le cas du fichier. Dire, par exemple, que le dépôt Git contient un renommage de "EXEMPLE" pour "l'exemple". Avant Git vérifie la nouvelle version, il va essayer et assurez-vous qu'il n'est pas d'écraser certains fichiers que vous avez sur votre disque. Car il pense que "exemple" est un nouveau nom de fichier, il vous demandera le système de fichiers, si elle existe, et le système de fichiers va voir "EXEMPLE" et de dire oui, donc, Git va refuser de voir la nouvelle version car il pense qu'il sera d'écraser sans traces de fichiers. Dans ce cas, si vous n'avez pas de changements locaux que vous vous souciez, un simple git reset --hard <revision-to-checkout> sera généralement suffisant pour vous le problème et à la nouvelle révision. Juste essayer de se rappeler de ne pas renommer les fichiers à d'autres noms qui diffèrent seulement dans le cas où si vous êtes sur un pas sensible à la casse du système de fichiers, comme cela va causer des problèmes de ce genre.

Answer 3

En règle générale, cela signifie que vous avez des modifications dans vos fichiers locaux qui n'ont pas été commis à votre dépôt local. Vous pouvez également voir ce stackoverflow question un peu plus en détail.

Answer 4

Il pourrait un problème aussi avec les autorisations de fichier. Git est versioning eux aussi, à moins que config dit le contraire. Juste l'ajout de cette réponse pour les personnes qui ont presque mais pas comme le problème.

Answer 5

Vaut la peine d'essayer:

Pourriez-vous définir, juste pour cette mise à jour, définissez la config paramètre core.trustctime de faux?

core.trustctime

Si la valeur est false, le ctime différences entre l'index et de la copie de travail sont ignorés, ce qui est utile lorsque l'inode le temps de changement est régulièrement modifiée par quelque chose d'extérieur à Git (système de fichiers robots et certains systèmes de sauvegarde).