git status montre des modifications, git checkout - ne les supprime pas

StackOverflow https://stackoverflow.com/questions/2016404

Question

Je voudrais supprimer toutes les modifications à la copie de travail.
L'exécution git status affiche les fichiers modifiés.
Rien ne semble que je supprimer ces modifications.
.:
par exemple 

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ 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:   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 <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." 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 <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." 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 <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." 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")
Était-ce utile?

La solution

Il y a plusieurs problèmes peuvent la provoquer ce problème:

la normalisation de fin de ligne

J'ai eu ce genre de problèmes aussi. Il se résume à git convertir automatiquement CRLF lf. Ceci est généralement causé par les fins de ligne mixtes dans un seul fichier. Le fichier est normalisé dans l'index, mais quand git dénormalise puis à nouveau pour diff contre le fichier dans l'arbre de travail, le résultat est différent.

Mais si vous voulez résoudre ce problème, vous devez désactiver core.autocrlf , changer toutes les fins de ligne à lf, puis 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 .gitattribute . De cette façon, vous pouvez faire tout le monde que l'aide de la prise en pension utilise les mêmes règles de normalisation, ce qui empêche les fins de ligne mixte d'entrer dans le dépôt.

Voir également le réglage du core.safecrlf pour avertira si vous voulez git pour vous avertir quand une normalisation non réversible serait effectuée.

Le manpages dire ceci:

  

conversion CRLF porte une petite chance   données de corrupteurs. autocrlf = true   convertir CRLF à la FL au cours de commettre et   LF à CRLF lors de votre commande. Un fichier   qui contient un mélange de LF et CRLF   avant que la livraison ne peut être recréée   par git. Pour les fichiers texte tel est le   bonne chose à faire: il corrige la ligne   fins telles que nous avons seulement la ligne LF   fins dans le référentiel. Mais pour   Les fichiers binaires accidentellement   classés comme la conversion texte peut   des données corrompues.

systèmes de fichiers sensibles à la casse

Sur les systèmes de fichiers insensibles à la casse, quand le même nom avec boîtier différent est dans le référentiel, git essaie de la caisse à la fois, mais seulement on finit sur le système de fichiers. Lorsque git essaie de comparer le second, il en le comparant au mauvais fichier.

La solution serait soit à un système de fichiers de commutation insensible non-cas, mais dans la plupart des cas est impossible ou de renommer et de commettre l'un des fichiers sur un autre système de fichiers.

Autres conseils

J'avais ce problème sur Windows mais n'a pas été prêt à se pencher sur les conséquences de l'utilisation config --global core.autocrlf false je aussi n'étais pas prêt à abandonner d'autres branches privées et de nombreux goodies dans ma cachette et commencer par un clone frais. J'ai juste besoin de faire quelque chose. Maintenant.

Cela a fonctionné pour moi, sur l'idée que vous laissez git Ressaisissez votre répertoire de travail complètement: 

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

(Notez que l'exécution juste git reset --hard était pas assez bon, ni était une rm plaine sur les fichiers avant la reset que sont proposées dans les commentaires à la question initiale)

Une autre solution qui peut fonctionner pour les gens, car aucune des options de texte a fonctionné pour moi:

  1. Remplacez le contenu de .gitattributes avec une seule ligne: * binary. Cela dit git pour traiter tous les fichiers sous forme de fichier binaire qui ne peut rien faire avec.
  2. Vérifiez que message pour les fichiers incriminés est allé; si ce n'est pas, vous pouvez git checkout -- <files> les restaurer à la version du référentiel
  3. git checkout -- .gitattributes pour restaurer le fichier .gitattributes à son état initial
  4. Vérifiez que les fichiers ne sont toujours pas marqués comme changé.

Pour les futurs personnes ayant ce problème: Avoir des changements de FileMode peuvent aussi avoir les mêmes symptômes. git config core.filemode false va fixer.

Cela a été me rend 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. Ne peut pas prendre les crédits ici puisque c'est le travail d'un collègue:)

Source du problème: Mon installation initiale de git était sans conversion de ligne automatique sur les fenêtres. Cela a provoqué mon premier engage à glfw être sans la fin de la ligne appropriée.

  

Note: Ceci est seulement une solution locale. Le gars à côté clonant le repo   sera coincé encore avec ce problème. Une solution permanente peut être   trouvé ici:    https://help.github.com/ articles / traitant avec ligne terminaisons / # re-normalisation-a-dépôt .

Configuration: Xubuntu 12.04 repo git avec le projet de glfw

Problème: Impossible de réinitialiser glfw fichiers. Ils montrent toujours modifié, peu importe ce que j'ai essayé.

Résolu: 

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

J'ai eu un fichier .bat avec le même problème (ne pouvait pas se débarrasser dans des fichiers non suivis). git checkout - ne fonctionne pas, ni fait aucune des suggestions sur cette page. La seule chose qui a fonctionné pour moi était de faire: 

git stash save --keep-index

Et puis supprimer la planque: 

git stash drop

Vous avez la même question deux fois! Les deux fois où Stash quelques changements que j'ai fait et essayé de les faire éclater en arrière. pop Could'nt les changements depuis que j'ai beaucoup de fichiers qui sont modifiés - mais ils ne sont pas! Ils sont exactement les mêmes.

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

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

Je suis maintenant presque tous les fichiers dans mon dépôt modifié.

Lorsque diffing le fichier, il dit que je l'ai supprimé toutes les lignes, puis les ajouter à nouveau.

Type de dérangeant. J'éviter maintenant stashing à l'avenir ..

La seule solution consiste à cloner un nouveau dépôt et recommencer. (Fait la dernière fois)

Je ne ai pu résoudre ce problème par le fichier temporaire suppression de .gitattributes de ma pension (qui définit * text=auto et *.c text).

Je courus git status après la suppression et les modifications ont disparu. Ils ne reviennent pas, même après .gitattributes a été mis en place.

Essayez de faire un

  

git checkout -f

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

Avoir des fins de ligne cohérente est une bonne chose. Par exemple, il ne se déclenche pas, mais se confond inutiles trivial. Je l'ai vu Visual Studio créer des fichiers avec des fins de ligne mixtes.

En outre, certains programmes comme bash (sous Linux) ne nécessitent que les fichiers .sh sont LF fin.

Pour que cela arrive, vous pouvez utiliser gitattributes. Il fonctionne au niveau du dépôt, peu importe ce que la valeur de autcrlf est.

Par exemple, vous pouvez avoir .gitattributes comme ceci:     * Text = auto

Vous pouvez également être plus précis par type / extension de fichier si elle a affaire dans votre cas.

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

Sur un mélange C # / C ++ / Java / Ruby / R, projet Windows / Linux ce fonctionne bien. Pas de problème jusqu'à présent.

J'ai aussi eu les mêmes symptômes, mais a été causée par différentes choses.

Je n'ai pas pu: 

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

même git rm --cached app.js il signe comme supprimé et dans les fichiers trassez je pouvais voir app.js. Mais quand j'ai essayé rm -rf app.js et peform git status encore, il me montre encore le fichier dans « untracked ».

Après quelques essais avec un collègue, nous avons découvert qu'il a été causé par Grunt!

Comme le Grunt a été activé, et parce que app.js a été généré à partir deux autres fichiers js nous avons constaté que, après chaque opération avec les fichiers js (également ce app.js) grogner recréer app.js à nouveau.

Ce problème peut également se produire lorsqu'un contributeur aux travaux repo sur une machine Linux ou Windows avec Cygwin et les autorisations de fichier sont modifiés. Git ne connaît que de 755 et 644.

Exemple de cette question et comment vérifier cela: 

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 git de configuration à l'aide correctement 

git config --global core.filemode false

Il y a beaucoup de solutions ici et je devrais peut-être ont essayé quelques-uns d'entre eux avant que je suis venu avec moi-même. Quoi qu'il en soit voici un plus ...

Notre problème est que nous n'avions pas l'application de lignes de fond et le dépôt avait un mélange de DOS / Unix. Pire encore était qu'il était en fait un repo open source dans cette position, et que nous avions en forme de fourche. La décision a été prise par ceux qui ont la propriété principale du référentiel OS pour changer toutes les lignes de fond à Unix et la validation a été fait qui comprenait un .gitattributes pour faire respecter les fins de ligne.

Malheureusement, cela semblait causer des problèmes beaucoup plus comme décrit ici où une fois une fusion de code à partir avant le DOS-2-Unix a été fait les fichiers serait à jamais marqué comme changé et ne pouvait pas être inversée.

Au cours de mes recherches pour ce que je suis tombé sur - https: //help.github.com/articles/dealing-with-line-endings/ -. Si je fais face à ce problème encore, je voudrais tout d'abord commencer par essayer ceci

Voici ce que je faisais:

  1. Je d'abord fait une fusion avant de réaliser que j'eu ce problème et a dû avorter que - git reset --hard HEAD ( Je suis tombé sur un conflit de fusion. Comment puis-je annuler la fusion? )

  2. J'ai ouvert les fichiers en question VIM et changé pour Unix (:set ff=unix). Un outil comme dos2unix pourrait être utilisé au lieu bien sûr

  3. commis

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

    git checkout old-code-branch; git merge master

  5. a résolu les conflits et les fichiers ont été DOS à nouveau et il fallait :set ff=unix quand dans vim. (Notez que j'ai installé https://github.com/itchyny/lightline.vim qui a permis moi de voir ce que le format de fichier est sur le statusline VIM)

  6. commis. Tout afficher!

Je me suis engagé tous les changements et fait et défais sur la validation. Cela a fonctionné pour moi

git add.

git commit -m "commit aléatoire"

git reset HEAD --hard ~ 1

Si vous cloner un dépôt et de voir instantanément les modifications en attente, le dépôt est dans un état incohérent. S'il vous plaît ne pas commenter * text=auto du fichier .gitattributes. Qu'il y avait mis spécifiquement parce que le propriétaire du dépôt veut que tous les fichiers stockés en conformité avec les fins de ligne LF.

Comme indiqué par HankCa, en suivant les instructions https: // aide .github.com / articles / traiter avec-fins de ligne / est la voie à suivre pour résoudre le problème. Bouton simple: 

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, la fusion (ou tirer demande) la branche au propriétaire de la pension.

La question que je suis tombé sur est que les fenêtres ne se soucient pas de la capitalisation des noms de fichiers, mais git fait. Donc git stocké une version inférieure et en majuscules du fichier, mais ne pouvait checkout un.

Rien d'autre sur cette page a fonctionné. Cela a finalement fonctionné pour moi. Afficher aucun fichier trassez ou Commited. 

git add -A
git reset --hard

Pour moi, le problème est que Visual Studio a été ouvert lors de l'exécution de la commande

git checkout <file>

Après la fermeture de Visual Studio et la commande travaillé je pourrais enfin appliquer mon travail de la pile. vérifier toutes les applications qui pourraient apporter des modifications à votre code, par exemple sources du, SmartGit, NotePad, notepad ++ et d'autres éditeurs.

Nous avons été confrontés à une situation similaire dans notre société. Aucune des méthodes proposées ne nous a pas aidés. En conséquence de la recherche, le problème a été révélé. La chose était que Git il y avait deux fichiers, dont les noms ne différaient que dans le registre des symboles. Unix systèmes les ont vus comme deux fichiers différents, mais Windows devenais fou. Pour résoudre le problème, nous avons supprimé l'un des fichiers sur le serveur. Après cela, les dépôts locaux sous Windows ont aidé les prochaines commandes (dans des séquences différentes): 

git reset --hard
git pull origin
git merge

J'ai couru plusieurs fois sur ce problème avant. Je développe actuellement sur machine Windows 10 fournie par mon employeur. Aujourd'hui, ce comportement git particulier a été causé par moi la création d'une nouvelle branche de ma branche « développement ». Pour une raison quelconque, après je suis revenu à « développer » branche, certains fichiers apparemment aléatoires a persisté et montraient comme « modifié » dans « git status ».

En outre, à ce moment-là, je ne pouvais pas la caisse une autre branche, donc je suis coincé sur ma branche « développement ».

Voici ce que je faisais: 

$ git log

J'ai remarqué que la nouvelle branche que j'ai créé de « développer » plus tôt aujourd'hui montrait dans le premier message « commit », référencée à la fin « HEAD -> développer, origine / développement, origine / HEAD, -branch-i-créé plus tôt aujourd'hui- ».

Depuis que je ne l'ai pas vraiment besoin, je l'ai effacé: 

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

Les fichiers modifiés sont toujours montrés, donc je l'ai fait: 

$ git stash

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 $ git stash list montrera les changements planquée, et depuis que j'avais peu et n'a pas besoin d'aucun de mes stashes, je l'ai fait $ git stash clear pour supprimer tous les Stashes.

NOTE : Je ne l'ai pas essayé de faire ce que quelqu'un a suggéré devant moi: 

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

Cela peut avoir fonctionné aussi bien, je serai sûr d'essayer la prochaine fois que je rencontre ce problème.

I résolu en modifiant .git / config, en ajoutant: 

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

Alors je suis allé à .git / refs / heads / name_branch et placez l'identifiant du dernier commitenter code here

Je l'ai résolu de cette façon:

  1. Copiez le contenu du code correct que vous voulez
  2. Supprimez le fichier qui est à l'origine du problème (celui que vous ne pouvez pas revenir) à partir de votre disque. Maintenant, vous devriez trouver les deux versions du même fichier marqué comme étant supprimé.
  3. Engagez la suppression des fichiers.
  4. Créer à nouveau le fichier avec le même nom et collez le bon code que vous avez copié à l'étape 1
  5. valider la création du nouveau fichier.

C'est ce qui a fonctionné pour moi.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top