Erreur Git: 7 fichier (s) rencontré (s) qui auraient dû être des pointeurs, mais qui n'étaient pas

Question

Comment nettoyer le référentiel, si les fichiers intermédiaires marqués comme modifiés

après

git reset --hard

Je reçois

7 fichier (s) rencontré (s) qui auraient dû être des pointeurs, mais qui n'étaient pas:

git clean -fdx

n'aide pas trop

Rian Sanderson · Answer

J'ai eu cette erreur exacte avec certains fichiers stockés avec git-LFS et résolu de la même manière que j'ai résolu un index borked induit par linending .

Videz le cache et effectuez une réinitialisation matérielle:

git rm --cached -r . git reset --hard

Ce fut significativement plus rapide qu'un nouveau clone pour moi en raison des énormes fichiers git-LFS dans mon référentiel.

BheeMa · Answer

Comme Travis Heeter mentionné dans sa réponse, essayez la séquence de commandes suivante:

git lfs uninstall

git reset --hard

git lfs install

git lfs pull

Si cela ne fonctionne pas (car cela ne fonctionnait pas pour moi), le hack suivant peut fonctionner:

Essayez les commandes suivantes:

git rm --cached -r .

git reset --hard

git rm .gitattributes

git reset .

git checkout .

Cela a fonctionné pour moi!

slythfox · Answer

Cela peut se produire lorsque vous effectuez une extraction qui contient des fichiers qui auraient dû être suivis par LFS comme spécifié dans .gitattributes mais ils ont été engagés directement à la place. Très probablement, vous avez un autre programme gérant votre référentiel tel qu'une interface graphique git ou un IDE.

Cela peut être frustrant car ces fichiers apparaissent de nulle part et vous empêchent d'effectuer des extractions. Dès que vous planquez vos modifications, elles reviennent! Si vous êtes bloqué dans cette situation, une solution rapide consiste à valider ces modifications sur une branche temporaire afin que vous puissiez reprendre la commande.

Pour résoudre réellement ce problème, assurez-vous d'avoir validé les fichiers en tant que pointeurs LFS. Cela devrait être aussi simple que d'utiliser git add. Vérifiez votre travail à l'aide de git lfs status avant de valider. git lfs ls-files affichera les fichiers gérés par LFS.

git lfs status est trompeur car il lit Git LFS objects to be committed quand il répertorie vraiment toutes les modifications. Le fichier que vous prévoyez de suivre par LFS doit lire quelque chose comme (LFS: c9e4f4a) ou (Git: c9e4f4a -> LFS: c9e4f4a) et pas (Git: c9e4f4a).

À titre d'exemple, j'ai trouvé que c'était un problème lors de l'ajout de ressources d'image via Xcode 9.2 où j'ai ajouté "CalendarChecked.png" qu'il a automatiquement ajouté.

$ git status Changes to be committed: (use "git reset HEAD <file>..." to unstage) new file: Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png $ git lfs status Git LFS objects to be committed: Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (Git: c9e4f4a) Git LFS objects not staged for commit: Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (File: c9e4f4a) $ git add Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png` $ git lfs status Git LFS objects to be committed: Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (LFS: c9e4f4a) Git LFS objects not staged for commit: $

Travis Heeter · Answer

Aucune de ces solutions n'a fonctionné pour moi, mais j'ai rassemblé quelques sources pour finalement résoudre tout cela.

Poussez toutes les modifications que vous ne voulez pas perdre

Assurez-vous que vous êtes dans votre branche principale et que tout est validé (sauf les mauvais fichiers).
Arrêtez tout

SourceTree, tous les serveurs, explorateurs de fichiers et navigateurs. Parfois, ce truc ne fonctionnera pas s'il est utilisé ailleurs. En cas de doute, arrêtez-le - avec cela, il vaut mieux exagérer.

Si vous passez par tout cela et que vos modifications ne persistent pas, envisagez de redémarrer votre ordinateur, d'arrêter de force tout ce qui pourrait affecter votre dépôt et de réessayer dans TaskManager.
Ouvrir une fenêtre de commande (ou un terminal)

Sous Windows, cela va être une fenêtre de commande cmd ou. Si vous n'êtes pas sûr, cliquez sur la touche Windows et tapez cmd. Il vous proposera une invite de commande, cliquez dessus.

cd à votre dépôt.
Désinstaller lfs

> git lfs uninstall

Ensuite, il dira quelque chose comme:

Hooks for this repository have been removed. Global Git LFS configuration has been removed.
Reset

> git reset --hard

Cela passera par beaucoup de sorties ...
Réinstaller lfs

> git lfs install

Cela peut encore dire qu'il a trouvé des fichiers qui auraient dû être des pointeurs mais qui ne l'étaient pas. Ça va, continuez !
Tirez avec lfs

> git lfs pull

Espérons que tirer avec lfs écrasera les fichiers qui ont été bloqués.

Quelques-unes de mes sources ont dit à ce stade que leur repo fonctionnait à nouveau, mais pas moi personnellement. Vous pouvez ouvrir SourceTree pour vérifier si vous le souhaitez, mais vous devrez peut-être commencer par le haut si cela ne fonctionne pas.
Migrer

Le problème principal ici est que lfs suit les gros fichiers en les remplaçant par des pointeurs. _{^{Si vous êtes un programmeur, cela ressemble à la façon dont une variable pointe vers un endroit en mémoire, plutôt que de conserver la valeur réelle.}}

Ce que nous avons fait jusqu'à présent, c'est
- désinstaller lfs
- tout supprimer
- réinstaller lfs
- tout tirer
Alors maintenant, nous avons tous ces choses dans notre dossier qui sont soit des fichiers ou pointeurs vers des fichiers , et lfs doit déterminer si des fichiers doivent être des pointeurs et vice versa (et voici la source de notre horrible erreur - certains fichiers auraient dû être pointeurs mais ne l'étaient pas). Nous allons donc exécuter migrate pour lancer la procédure qui parcourt les fichiers du dépôt, et s'ils sont supérieurs à 1 Mo, lfs va les remplacer par un pointeur.

git lfs migrate
Plus d'horreur

Voici un point où d'autres se sont arrêtés et ont dit qu'ils travaillaient à nouveau, mais pas moi. J'ai une erreur:

Erreur dans git rev-list ... exit status 128 fatal: bad revision '...v1.0.0 '

Il y a un héros tragique, @guneyozsan sur une page d'aide github , qui a posté cette dernière pièce du puzzle même si cela n'a pas résolu son problème. Il l'a posté environ 2 heures avant de commencer à chercher la dix-neuvième fois sur la façon de résoudre ce problème, même si le problème existe depuis 2 ans. Que Dieu vous bénisse @guneyozsan, et je vous souhaite bonne chance pour résoudre votre problème.

> git lfs migrate info --include-ref=v1.0.0

Notez que la version correspond à la version qui a commis une erreur - v1.0.0.

Je n'ai pas trouvé de source expliquant pourquoi cette erreur se produit, mais je suppose que le numéro de version lfs généré par migrate sur votre référentiel local ne correspond pas à la version source. Pour une raison quelconque, les données lfs locales ont été vissées (pour moi, tout cela a commencé lorsque SourceTree s'est écrasé lors d'un Push et j'ai forcé un redémarrage de la machine, de sorte que cela peut avoir corrompu les données lfs), et lorsque cela se produit, SourceTree ne fonctionne pas savoir comment y faire face, il reste donc coincé dans cette boucle où il essaie de se mettre à jour, mais il ne peut pas lire les données corrompues. D'où le long dépannage.
Stash and Pull

Lorsque vous ouvrez SourceTree, vous verrez probablement qu'il souhaite ajouter tous vos fichiers. Ne fais pas ça. Stash, puis tirez .

Et boum, l'horreur est finie. J'espère. Sinon, cette page du hub git ou celle-ci peut vous aider davantage, mais c'est ce qui a fonctionné pour moi.

Felix · Answer

Assurez-vous d'avoir git lfs version 2.5 ou supérieure installée ( télécharger ici ).

Vérifiez que vous utilisez le git lfs version que vous avez téléchargée (2.7.7 pour moi):

>git lfs version git-lfs/2.7.2

Courir:

git lfs migrate import --fixup --everything

Tirez votre branche et corrigez les conflits de fusion.

Trouvé dans ce commentaire github .

Archy · Answer

Le processus suivant ajoutera une validation qui remplace tous les fichiers binaires qui devraient être des pointeurs lfs par des pointeurs lfs.

Nettoyez complètement la copie de travail. Associé à l'ajout forcé ci-dessous, cela empêche l'ajout ou la suppression de fichiers en raison de modèles .gitignore.
```
git clean -dfx git reset --hard git checkout -- . 
```
Ajoutez supprimer pour tout dans la zone de transit. La copie de travail ne sera pas touchée.
```
git rm --cached -r . 
```
A nouveau lu tous les fichiers de la copie de travail. Cela annulera essentiellement la commande précédente mais réévaluera les filtres lfs. Utilisez -f pour ignorer .gitignore. Tous les fichiers présents ont déjà été archivés et devraient être ajoutés à nouveau.
```
git add -f . 
```
Votre zone de transit ne doit maintenant contenir que les fichiers binaires qui ont précédemment déclenché l'erreur "aurait dû être des pointeurs".
```
git commit -m "moved files to lfs" 
```

karyon · Answer

Depuis git lfs 2.5.0, il existe une nouvelle commande disponible qui facilite cela ( docs ):

git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...

Cela "migre" les fichiers vers git lfs qui devrait être dans lfs selon .gitattributes, mais ne le sont pas pour le moment (c'est la raison de votre message d'erreur).

--no-rewrite empêche git de l'appliquer à des validations plus anciennes, il crée à la place une nouvelle validation.

Utilisation -m "commitmessage" pour définir un message de validation pour cette validation.

darkgaze · Answer

Quand c'est évidemment une erreur qui surgit de nulle part, c'est ce que nous faisons dans notre équipe:

Désactivez lfs pour ce fichier de type spécifique (en modifiant .gitattributes ou via les menus SourceTree)
Le changement disparaîtra et vous verrez un changement sur .gitattributes à la place
Supprimez le problème:

3.1 Une solution consiste à exécuter git reset --hard. Sinon, supprimez les modifications. Parfois, le fichier ne réapparaît pas.

3.2.1 Si la solution précédente ne fonctionne pas, répétez 1 et 2. Assurez-vous ensuite que cette branche dans laquelle vous êtes (A) a déjà validé et poussé tout sauf ces fichiers ennuyeux. Validez ensuite votre modification, mais pas Push.

3.2.2: Aller dans une autre branche (B)

3.2.3: Supprimez la branche locale (A) où vous avez effectué la validation sur .gitattributes, forçant la suppression même lorsqu'il indique qu'il y a une validation qui n'a pas été poussée. Il oubliera ce commit (il peut ensuite être supprimé via GC ou autre mais ce n'est pas grave si le fichier qui contient l'erreur n'est pas énorme)

3.2.4: Extraire à nouveau la branche A. Il téléchargera l'état précédent du référentiel sans que les fichiers ennuyeux et les paramètres LFS soient configurés correctement.

Ça marche toujours!

sonny · Answer

Une cause possible de cette erreur est en raison des changements liés à git LFS dans .gitattributes qui impacte les fichiers déjà ajoutés dans un dépôt.

(Je ne suis pas sûr des étapes exactes à reproduire, mais le problème semblait se produire lorsque je touchais un fichier qui était nouvellement affecté par les attributs .gitattributes qui étaient précédemment validés en tant que fichier non LFS qui devrait maintenant être un fichier LFS. Le problème semblait aggravé par le changement de branche, ou du moins il était impossible de changer de branche jusqu'à ce que le problème soit résolu.)

Dans ce cas, j'ai utilisé les étapes ci-dessous pour éviter que cette erreur ne se reproduise .

Résolvez le problème de la branche sur laquelle vous vous trouvez en suivant l'une des autres réponses ici (par exemple, pour vider le cache et réinitialiser. J'ai trouvé la réponse de BheeMa pour être efficace.)
Accédez à votre branche principale et assurez-vous qu'il n'y a rien à valider avec git status
Forcer git à revérifier et "réappliquer" les changements d'attributs git

De réponse de Ratata Tata in Comment faire pour changer les .gitattributes prennent effet )

 git rm --cached -r . git add -A

Attention: assurez-vous à l'étape 2 qu'il n'y avait rien à valider, car les étapes ci-dessus ajouteront tous les fichiers qui n'ont pas été versionnés auparavant

Vérifiez les résultats avec git status (il ne doit avoir modifié que les fichiers pertinents pour devenir des pointeurs LFS, c'est-à-dire des fichiers qui peuvent potentiellement provoquer l'erreur "fichiers rencontrés qui auraient dû être des pointeurs") et valider les modifications
(Vous pouvez éventuellement fusionner/rebaser ce correctif dans toutes les autres branches si possible. Sinon, cette erreur pourrait réapparaître lors du passage à ces branches. Notez qu'il peut être nécessaire de répéter le correctif initial pour chaque branche selon l'étape 1 pour être sûr. , bien qu'il soit possible de valider les fichiers concernés.)