statut git affiche les modifications, git checkout – ne les supprime pas

Je voudrais supprimer toutes les modifications apscopes à ma copie de travail.
Running git status affiche les fichiers modifiés.
Rien que je fasse ne semble supprimer ces modifications.
Par exemple:

 rbellamy@PROMETHEUS /d/Development/rhino-etl (master) $ git status # On branch master # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: Rhino.Etl.Core/Enumerables/CachingEnumerable.cs # modified: Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs # modified: Rhino.Etl.Tests/Rhino.Etl.Tests.csproj # modified: Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs # no changes added to commit (use "git add" and/or "git commit -a") rbellamy@PROMETHEUS /d/Development/rhino-etl (master) $ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs rbellamy@PROMETHEUS /d/Development/rhino-etl (master) $ git status # On branch master # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: Rhino.Etl.Core/Enumerables/CachingEnumerable.cs # modified: Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs # modified: Rhino.Etl.Tests/Rhino.Etl.Tests.csproj # modified: Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs # no changes added to commit (use "git add" and/or "git commit -a") rbellamy@PROMETHEUS /d/Development/rhino-etl (master) $ git checkout `git ls-files -m` rbellamy@PROMETHEUS /d/Development/rhino-etl (master) $ git status # On branch master # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: Rhino.Etl.Core/Enumerables/CachingEnumerable.cs # modified: Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs # modified: Rhino.Etl.Tests/Rhino.Etl.Tests.csproj # modified: Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs # no changes added to commit (use "git add" and/or "git commit -a") rbellamy@PROMETHEUS /d/Development/rhino-etl (master) $ git reset --hard HEAD HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated. rbellamy@PROMETHEUS /d/Development/rhino-etl (master) $ git status # On branch master # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: Rhino.Etl.Core/Enumerables/CachingEnumerable.cs # modified: Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs # modified: Rhino.Etl.Tests/Rhino.Etl.Tests.csproj # modified: Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs # no changes added to commit (use "git add" and/or "git commit -a") 

Il existe plusieurs problèmes qui peuvent provoquer ce comportement:

Normalisation de fin de ligne

J’ai aussi eu ce genre de problèmes. Cela revient à convertir automatiquement crlf en lf. Cela est généralement dû à des fins de ligne mixtes dans un seul fichier. Le fichier est normalisé dans l’index, mais lorsque git le dénormalise à nouveau pour le différencier du fichier dans l’arborescence de travail, le résultat est différent.

Mais si vous voulez résoudre ce problème, vous devez désactiver core.autocrlf , modifier toutes les fins de ligne en lf, puis l’activer à nouveau. Ou vous pouvez le désactiver complètement en faisant:

 git config --global core.autocrlf false 

Au lieu de core.autocrlf , vous pouvez également envisager d’utiliser des fichiers .gitatsortingbute . De cette façon, vous pouvez vous assurer que tous ceux qui utilisent le référentiel utilisent les mêmes règles de normalisation, empêchant les terminaisons de lignes mixtes d’entrer dans le référentiel.

Pensez également à définir core.safecrlf pour avertir si vous souhaitez que git vous avertisse lorsqu’une normalisation non réversible sera effectuée.

Les pages de manuel git disent ceci:

La conversion CRLF risque légèrement de corrompre les données. autocrlf = true convertira CRLF en LF lors de la validation et LF en CRLF lors de la validation. Un fichier contenant un mélange de LF et de CRLF avant la validation ne peut pas être recréé par git. Pour les fichiers texte, c’est la bonne chose à faire: elle corrige les fins de ligne de telle sorte que nous n’avons que des fins de ligne LF dans le référentiel. Mais pour les fichiers binarys classés accidentellement comme du texte, la conversion peut corrompre les données.

Systèmes de fichiers insensibles à la casse

Sur les systèmes de fichiers insensibles à la casse, lorsque le même nom de fichier avec un boîtier différent se trouve dans le référentiel, git essaie de récupérer les deux, mais un seul se retrouve sur le système de fichiers. Lorsque git essaie de comparer le second, il le compare au mauvais fichier.

La solution serait soit de basculer vers un système de fichiers insensible à la casse, mais dans la plupart des cas, ce n’est pas possible ou de renommer et de valider l’un des fichiers sur un autre système de fichiers.

J’avais ce problème sous Windows, mais je n’étais pas prêt à examiner les config --global core.autocrlf false de l’utilisation de config --global core.autocrlf false Je n’étais pas non plus prêt à abandonner d’autres twigs et produits privés et à commencer par un nouveau clone. J’ai juste besoin de faire quelque chose. À présent.

Cela a fonctionné pour moi, sur l’idée que vous laissiez git réécrire complètement votre répertoire de travail:

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

(Notez que git reset --hard juste git reset --hard n’était pas assez bon et il n’y avait pas vraiment de rm sur les fichiers avant la reset comme le suggèrent les commentaires à la question d’origine)

Une autre solution qui peut fonctionner pour les gens, car aucune des options de texte ne fonctionnait pour moi:

  1. Remplacez le contenu de .gitatsortingbutes par une seule ligne: * binary . Cela dit à git de traiter chaque fichier comme un fichier binary avec lequel il ne peut rien faire.
  2. Vérifiez que le message pour les fichiers incriminés est parti; si ce n’est pas vous pouvez git checkout -- pour les restaurer dans la version du référentiel
  3. git checkout -- .gitatsortingbutes pour restaurer le fichier .gitatsortingbutes dans son état initial
  4. Vérifiez que les fichiers ne sont toujours pas marqués comme modifiés.

Pour les futurs utilisateurs qui rencontrent ce problème: les modifications de mode de fichier peuvent également avoir les mêmes symptômes. git config core.filemode false le corrigera.

Cela m’a rendu fou, surtout que je ne pouvais pas résoudre ce problème sans aucune des solutions trouvées en ligne. Voici comment je l’ai résolu. Je ne peux pas prendre les crédits ici car c’est le travail d’un collègue 🙂

Source du problème: Mon installation initiale de git était sans conversion de ligne automatique sur Windows. Cela a causé mon engagement initial à GLFW sans la fin de ligne correcte.

Note: Ceci est seulement une solution locale. Le prochain gars qui clonera le repository sera toujours coincé avec ce problème. Une solution permanente peut être trouvée ici: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

Configuration: repo Xubuntu 12.04 Git avec projet glfw

Problème: Impossible de réinitialiser les fichiers glfw. Ils montrent toujours comme modifié, indépendamment de ce que j’ai essayé.

Résolu:

 edit .gitatsortingbutes Comment out the line: # text=auto Save the file restore .gitatsortingbutes: git checkout .gitatsortingbutes 

J’ai eu un fichier .bat avec le même problème (impossible de le supprimer dans des fichiers non suivis). Git checkout – n’a pas fonctionné, pas plus que les suggestions sur cette page. La seule chose qui a fonctionné pour moi était de faire:

 git stash save --keep-index 

Et ensuite pour supprimer la cachette:

 git stash drop 

Je n’ai pu résoudre ce problème qu’en supprimant temporairement le fichier .gitatsortingbutes de mon repository (qui a défini * text=auto et *.c text ).

J’ai exécuté git status après la suppression et les modifications ont disparu. Ils ne sont pas revenus même après la remise en place de .gitatsortingbutes.

Vous avez le même problème deux fois! Les deux fois où il y a des changements que j’ai faits, puis j’ai essayé de les faire revenir. N’a pas pu afficher les changements depuis que j’ai beaucoup de fichiers qui ont été modifiés – mais ils ne le sont PAS! Ils sont exactement les mêmes.

Je pense maintenant que j’ai essayé toutes les solutions ci-dessus sans succès. Après avoir essayé le

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

J’ai maintenant presque tous les fichiers de mon référentiel modifiés.

En différant le fichier, il est dit que j’ai supprimé toutes les lignes et que je les ai ensuite rajoutées.

Genre de déranger. Je vais maintenant éviter de me cacher à l’avenir.

La seule solution consiste à cloner un nouveau référentiel et à recommencer. (Fait la dernière fois)

Avoir des fins de ligne cohérentes est une bonne chose. Par exemple, cela ne déclenchera pas de fusions inutiles, quoique sortingviales. J’ai vu Visual Studio créer des fichiers avec des fins de ligne mixtes.

De plus, certains programmes comme bash (sous Linux) exigent que les fichiers .sh soient terminés par LF.

Pour vous en assurer, vous pouvez utiliser gitatsortingbutes. Il fonctionne au niveau du référentiel, quelle que soit la valeur de autcrlf.

Par exemple, vous pouvez avoir des atsortingbuts .git comme ceci: * text = auto

Vous pouvez également être plus spécifique par type de fichier / extension si cela importait dans votre cas.

Ensuite, autocrlf peut convertir les fins de ligne pour les programmes Windows localement.

Sur un projet mixte C # / C ++ / Java / Ruby / R, Windows / Linux, cela fonctionne bien. Pas de problèmes jusqu’ici.

J’ai également eu les mêmes symptômes mais a été causé par autre chose.

Je n’étais pas capable de:

 git checkout app.js //did nothing git rm app.js //did nothing rm -rf app.js //did nothing 

même sur git rm --cached app.js il signe comme supprimé et dans les fichiers non suivis je pourrais voir app.js. Mais lorsque j’ai essayé rm -rf app.js et que j’effectue à nouveau l’ git status le fichier est toujours “non suivi”.

Après quelques essais avec un collègue, nous avons découvert que cela avait été causé par Grunt!

Comme Grunt a été activé, et que app.js a été généré à partir de deux autres fichiers js, nous avons découvert qu’après chaque opération avec des fichiers js (également cette application.js), recréer à nouveau app.js.

Il y a beaucoup de solutions ici et j’aurais peut-être dû essayer certaines d’entre elles avant de proposer la mienne. Quoi qu’il en soit, en voici un de plus …

Notre problème était que nous n’avions aucune application pour les lignes de fin et que le repository contenait un mélange de DOS / Unix. Pire encore, c’était qu’il s’agissait en fait d’un repository en libre access dans cette position, et que nous avions tranché. La décision a été prise par les détenteurs principaux du référentiel de système d’exploitation de modifier toutes les fins de ligne sous Unix et la validation incluant un .gitatsortingbutes pour appliquer les fins de ligne.

Malheureusement, cela semblait causer des problèmes similaires à ceux décrits ici, où une fois la fusion du code effectuée avant le DOS-2-Unix, les fichiers seraient marqués comme modifiés et ne pourraient plus être annulés.

Au cours de mes recherches pour cela, je suis tombé sur – https://help.github.com/articles/dealing-with-line-endings/ – Si je suis confronté à ce problème, je commencerai d’abord par essayer.


Voici ce que j’ai fait:

  1. Au début, j’avais fait une fusion avant de me rendre compte que j’avais ce problème et que je devais interrompre cette opération – git reset --hard HEAD ( j’ai rencontré un conflit de fusion. Comment puis-je abandonner la fusion? )

  2. J’ai ouvert les fichiers en question dans VIM et changé pour Unix ( :set ff=unix ). Un outil comme dos2unix pourrait être utilisé à la place

  3. engagé

  4. fusionné le master dans (le maître a les modifications DOS-2-Unix)

    git checkout old-code-branch; git merge master

  5. Les conflits résolus et les fichiers DOS à nouveau devaient donc :set ff=unix dans VIM. (Remarque: J’ai installé https://github.com/itchyny/lightline.vim ce qui m’a permis de voir le format du fichier sur la ligne d’état VIM)

  6. engagé. Tous sortingés!

Ce problème peut également survenir lorsqu’un consortingbuteur au référentiel fonctionne sur une machine Linux ou que Windows avec Cygwin et les permissions de fichiers sont modifiés. Git ne connaît que 755 et 644.

Exemple de ce problème et comment le vérifier:

 git diff styleguide/filename diff --git a/filename b/filename old mode 100644 new mode 100755 

Pour éviter cela, vous devez vous assurer que vous configurez correctement git en utilisant

 git config --global core.filemode false 

Le problème que j’ai rencontré est que Windows ne se soucie pas de la capitalisation des noms de fichiers, mais git le fait. Donc, git stocke une version inférieure et majuscule du fichier mais ne peut en extraire qu’une seule.

Si vous clonez un référentiel et voyez instantanément les modifications en attente, le référentiel est dans un état incohérent. Veuillez NE PAS commenter * text=auto partir du fichier .gitatsortingbutes . Cela a été mis là précisément parce que le propriétaire du référentiel souhaite que tous les fichiers soient stockés de manière cohérente avec les fins de ligne LF.

Comme indiqué par HankCa, suivre les instructions sur https://help.github.com/articles/dealing-with-line-endings/ est la voie à suivre pour résoudre le problème. Bouton facile:

 git clone git@host:repo-name git checkout -b normalize-line-endings git add . git commit -m "Normalize line endings" git push git push -u origin normalize-line-endings 

Ensuite, fusionnez (ou extrayez la requête) la twig vers le propriétaire du repository.

Rien d’autre sur cette page n’a fonctionné. Cela a finalement fonctionné pour moi. Ne montrant aucun fichier non suivi ou commis.

 git add -A git reset --hard 

Essayez de faire un

git checkout -f

Cela devrait effacer tous les changements dans le repo local de travail actuel

J’ai engagé tous les changements, puis je l’ai fait et j’ai annulé le commit. Cela a fonctionné pour moi

git add.

git commit -m “Commencement aléatoire”

git réinitialiser –hard HEAD ~ 1

Nous avons été confrontés à une situation similaire dans notre société. Aucune des méthodes proposées ne nous a pas aidé. À la suite de la recherche, le problème a été révélé. La chose était que dans Git il y avait deux fichiers, dont les noms différaient seulement dans le registre des symboles. Les systèmes Unix les considéraient comme deux fichiers différents, mais Windows devenait fou. Pour résoudre le problème, nous avons supprimé l’un des fichiers sur le serveur. Après cela, dans les référentiels locaux de Windows ont aidé les commandes suivantes (dans différentes séquences):

 git reset --hard git pull origin git merge 

Pour moi, le problème était que Visual Studio était ouvert lors de l’exécution de la commande

git checkout

Après avoir fermé Visual Studio, la commande a fonctionné et je pouvais enfin appliquer mon travail à partir de la stack. Vérifiez donc toutes les applications susceptibles d’apporter des modifications à votre code, par exemple SourceTree, SmartGit, NotePad, NotePad ++ et d’autres éditeurs.

J’ai rencontré ce problème quelques fois auparavant. Je développe actuellement sur Windows 10 une machine fournie par mon employeur. Aujourd’hui, ce comportement particulier a été causé par la création d’une nouvelle twig à partir de ma twig “développer”. Pour une raison quelconque, après être revenu à “développer” la twig, certains fichiers apparemment aléatoires ont persisté et apparaissaient comme “modifiés” dans “git status”.

Aussi, à ce moment-là, je ne pouvais pas commander une autre twig, alors j’étais coincé dans ma twig “développer”.

C’est ce que j’ai fait:

 $ git log 

J’ai remarqué que la nouvelle twig que j’avais créée à partir de “développer” plus tôt aujourd’hui apparaissait dans le premier message “commit”, référencé à la fin “HEAD -> develop, origin / develop, origin / HEAD, The-branch-i-created -avant-hier “.

Comme je n’en avais pas vraiment besoin, je l’ai supprimé:

 $ git branch -d The-branch-i-created-earlier-today 

Les fichiers modifiés apparaissaient toujours, alors j’ai fait:

 $ git stash 

Ceci a résolu mon problème:

 $ git status On branch develop Your branch is up to date with 'origin/develop'. nothing to commit, working tree clean 

Bien sûr, la $ git stash list affichera les modifications cachées, et comme j’avais peu et que je n’avais besoin d’aucune de mes cachettes, je ne me suis pas gêné pour $ git stash clear TOUTES LES CACHES.

NOTE : Je n’ai pas essayé de faire ce que quelqu’un a suggéré ici avant moi:

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

Cela a peut-être aussi bien fonctionné, je ne manquerai pas de l’essayer la prochaine fois que je rencontrerai ce problème.