Git : Comment revenir sur 2 fichiers qui sont obstinément bloqués à "Changed but not committed" ?

Question

J'ai un repo qui contient deux fichiers que j'ai soi-disant modifiés localement.

Je suis donc coincé avec ça :

$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   dir1/foo.aspx
#       modified:   dir2/foo.aspx
#
no changes added to commit (use "git add" and/or "git commit -a")

Faire git diff indique que l'ensemble du contenu du fichier a changé, même si, à l'œil nu, cela semble faux (il semble y avoir des plages de lignes communes que diff ne semble pas voir).

Il est intéressant de noter que je ne me souviens pas avoir modifié ces fichiers localement. Ce repo est utilisé avec un repo distant (privé, sur GitHub.com, FWIW).

J'ai beau essayer, je ne parviens pas à me débarrasser de ces modifications locales. J'ai essayé tous les :

$ git checkout -- .
$ git checkout -f
$ git checkout -- dir1/checkout_receipt.aspx
$ git reset --hard HEAD
$ git stash save --keep-index && git stash drop
$ git checkout-index -a -f

En d'autres termes, j'ai essayé tout ce qui est décrit dans le document Comment supprimer les modifications non mises à jour dans Git ? et plus encore. Mais les deux fichiers restent bloqués en tant que "modifiés mais non validés".

Qu'est-ce qui peut bien faire que deux fichiers soient bloqués de la sorte et que l'on ait l'impression qu'il faut "déréviser la table" ?

P.S. Dans la liste ci-dessus des commandes que j'ai déjà essayées, j'ai écrit par erreur git revert alors que je voulais dire git checkout . Je suis désolée et je remercie ceux qui m'ont répondu que je devais essayer. checkout . J'ai édité la question pour la corriger. Il est certain que j'ai déjà essayé checkout .

Answer 1

J'ai passé des heures à essayer de résoudre un problème similaire - une branche distante que j'avais extraite et qui affichait obstinément quatre fichiers comme "modifiés mais non mis à jour", même en supprimant tous les fichiers et en exécutant la commande git checkout -f (ou d'autres variantes de ce billet) !

Ces quatre fichiers étaient nécessaires, mais n'avaient certainement pas été modifiés par moi. Ma solution finale - persuader Git qu'ils n'ont pas été modifiés. Ce qui suit fonctionne pour tous les fichiers sortis, montrant le statut 'modifié' - assurez-vous que vous avez déjà commis/jeté tous ceux qui ont vraiment été modifiés !

git ls-files -m | xargs -i git update-index --assume-unchanged "{}"

Sur Mac OSX, cependant, xargs fonctionne un peu différemment (merci Daniel pour le commentaire) :

git ls-files -m | xargs -I {} git update-index --assume-unchanged {}

Je l'ai ajouté à ma liste pour la prochaine fois.

Answer 2

Quelles sont les fins de ligne dans les fichiers ? Je parie qu'il s'agit de CRLF. Si c'est le cas, consultez ce guide : http://help.github.com/line-endings/

En bref, vous devez vous assurer que git est configuré pour convertir les fins de ligne en LF lors de la validation, puis valider ces fichiers. Les fichiers dans le repo devraient toujours être en LF, les fichiers sortis devraient être ceux du système d'exploitation, en supposant que vous ayez configuré git correctement.

Answer 3

Voici comment j'ai résolu le même problème dans mon cas : ouvrir .gitattributes change :

* text=auto

à :

#* text=auto

Plus d'informations ici https://code.visualstudio.com/docs/remote/troubleshooting#_resolving-git-line-ending-issues-in-containers-resulting-in-many-modified-files

enregistrer et fermer, puis inverser ou réinitialiser, merci à @Simon East pour l'astuce

Answer 4

Une autre possibilité est que la différence (qui vous empêche d'annuler ces fichiers avec une commande d'extraction) est une différence de mode de fichier. C'est ce qui m'est arrivé. Sur ma version de git, vous pouvez le découvrir en utilisant

git diff dir1/foo.aspx

Il vous indiquera les changements de mode de fichier. Cependant, il ne vous permettra toujours pas de les annuler. Pour cela, utilisez soit

git config core.filemode false

ou modifiez votre git .config dans votre éditeur de texte en ajoutant

[core]

filemode = false

Après cela, vous pouvez utiliser

git reset HEAD dir1/foo.aspx

et le fichier devrait disparaître.

(J'ai tiré tout cela de la réponse à la question suivante Comment faire en sorte que git ignore les changements de mode (chmod) ? )

Answer 5

J'ai eu le même problème, avec l'ajout intéressant que les fichiers étaient modifiés sous Windows, mais pas lorsqu'on les regardait à partir de WSL. Je n'ai pas réussi à modifier les fins de ligne, les réinitialisations, etc.

J'ai fini par trouver une solution dans cette réponse . Voici le texte pour plus de commodité :

---

J'ai résolu ce problème en suivant les étapes suivantes

1) Supprimer tous les fichiers de l'index de Git.

git rm --cached -r .

2) Réécrire l'index Git pour prendre en compte toutes les nouvelles fins de ligne.

git reset --hard

La solution faisait partie des étapes décrites sur le site git https://help.github.com/articles/dealing-with-line-endings/