l'état de git montre des modifications, git checkout - <fichier> ne les supprime pas

Je souhaite supprimer toutes les modifications apportées à ma copie de travail.
L'exécution git statusmontre les fichiers modifiés.
Rien de ce que je fais 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 <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")

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

Normalisation de fin de ligne

J'ai aussi eu ce genre de problèmes. Cela revient à git 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 souhaitez résoudre ce problème, vous devez désactiver core.autocrlf , remplacer toutes les fins de ligne par lf, puis le réactiver . 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 .gitattributefichiers. De cette façon, vous pouvez vous assurer que toutes les personnes utilisant le référentiel utilisent les mêmes règles de normalisation, empêchant les fins de ligne mixtes d'entrer dans le référentiel.

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

Les pages de manuel git disent ceci:

La conversion CRLF a une légère chance de corrompre les données. autocrlf = true convertira CRLF en LF lors de la validation et LF en CRLF lors du paiement. Un fichier qui contient un mélange de LF et CRLF avant la validation ne peut pas être recréé par git. Pour les fichiers texte, c'est la bonne chose à faire: cela 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 binaires qui sont accidentellement classés 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 une casse différente se trouve dans le référentiel, git essaie de retirer 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 passer à un système de fichiers non sensible à la casse, mais dans la plupart des cas, cela 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 sur Windows, mais je n'étais pas prêt à étudier les ramifications de l'utilisation. config --global core.autocrlf falseJe n'étais pas non plus prêt à abandonner d'autres branches privées et goodies dans ma cachette et à commencer avec un nouveau clone. J'ai juste besoin de faire quelque chose. Maintenant.

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 l'exécution git reset --hardn'était tout simplement pas assez bonne ni une plaine rmsur les fichiers avant le resetcomme suggéré dans les commentaires de la question d'origine)

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

1. Remplacez le contenu .gitattributesavec une seule ligne: * binary. Cela indique à git de traiter chaque fichier comme un fichier binaire avec lequel il ne peut rien faire.
2. Vérifiez que le message pour les fichiers incriminés a disparu; si ce n'est pas le cas, vous pouvez git checkout -- <files>les restaurer dans la version du référentiel
3. git checkout -- .gitattributesrestaurer le .gitattributesfichier à son état initial
4. Vérifiez que les fichiers ne sont toujours pas marqués comme modifiés.

Pour les futures personnes ayant ce problème: Les modifications du mode de fichier peuvent également présenter les mêmes symptômes. git config core.filemode falseva le réparer.

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 s'est faite sans conversion de ligne automatique sur Windows. Cela a provoqué mon commit initial à GLFW sans la fin de ligne appropriée.

Remarque: ce n'est qu'une solution locale. Le prochain gars clonant le dépôt 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 .

Installation: Xubuntu 12.04 Git repo avec projet glfw

Problème: impossible de réinitialiser les fichiers glfw. Ils apparaissent toujours comme modifiés, indépendamment de ce que j'ai essayé.

Résolu:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

J'avais un fichier .bat avec le même problème (impossible de le supprimer dans les fichiers non suivis). git checkout - n'a pas fonctionné, ni aucune des suggestions sur cette page. La seule chose qui a fonctionné pour moi a été de faire:

git stash save --keep-index

Et puis pour supprimer la cachette:

git stash drop

Vous avez le même problème deux fois! Les deux fois où j'ai caché des changements, j'ai fait et j'ai essayé de les faire revenir. Impossible de faire apparaître les modifications car 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 modifié presque tous les fichiers de mon référentiel.

Lorsque vous différez le fichier, il indique que j'ai supprimé toutes les lignes, puis les ai ajoutées à nouveau.

Un peu dérangeant. Je vais maintenant éviter de planquer à l'avenir ..

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

Essayez de faire un

git checkout -f

Cela devrait effacer tous les changements dans le référentiel local de travail actuel

Je n'ai pu résoudre ce problème qu'en supprimant temporairement le fichier .gitattributes de mon référentiel (qui définissait * text=autoet *.c text).

J'ai couru git statusaprès la suppression et les modifications avaient disparu. Ils ne sont pas revenus même après la remise en place de .gitattributes.

Avoir des fins de ligne cohérentes est une bonne chose. Par exemple, il ne déclenchera pas de fusions inutiles, bien que triviales. J'ai vu Visual Studio créer des fichiers avec des fins de ligne mixtes.

Certains programmes comme bash (sous linux) nécessitent également que les fichiers .sh soient terminés en LF.

Pour vous assurer que cela se produit, vous pouvez utiliser gitattributes. Il fonctionne au niveau du référentiel quelle que soit la valeur de autcrlf.

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

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

Autocrlf peut alors convertir localement les fins de ligne pour les programmes Windows.

Sur un projet mixte C # / C ++ / Java / Ruby / R, Windows / Linux, cela fonctionne bien. Aucun problème jusqu'à présent.

J'ai également eu les mêmes symptômes mais a été causée par une chose différente.

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.jscelui-ci signe comme supprimé et dans les fichiers non suivis, je pouvais voir app.js. Mais quand j'ai essayé rm -rf app.jset peform git statusencore , il me montre encore le fichier dans « untracked ».

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

Comme le Grunta été activé, et parce que app.js a été généré à partir de quelques autres fichiers js, nous avons découvert qu'après chaque opération avec des fichiers js (également ce app.js) grunt recrée à nouveau app.js.

Ce problème peut également se produire lorsqu'un contributeur au dépôt fonctionne sur une machine Linux ou lorsque les fenêtres avec Cygwin et les autorisations de fichier sont modifiées. 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 de configurer correctement git en utilisant

git config --global core.filemode false

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

Notre problème était que nous n'avions aucune application pour les endlines et le référentiel avait un mélange de DOS / Unix. Le pire, c'est qu'il s'agissait en fait d'un référentiel open source dans cette position, et que nous avions bifurqué. La décision a été prise par ceux qui détiennent la propriété principale du référentiel du système d'exploitation de changer toutes les lignes de terminaison en Unix et la validation a été prise qui comprenait un .gitattributespour appliquer les fins de ligne.

Malheureusement, cela semblait causer des problèmes similaires à ceux décrits ici où une fois une fusion de code antérieure à DOS-2-Unix effectuée, les fichiers seraient marqués pour toujours comme modifiés et ne pourraient pas être annulés.

Au cours de mes recherches à ce sujet, je suis tombé sur - https://help.github.com/articles/dealing-with-line-endings/ - Si je fais à nouveau face à ce problème, je commencerais par essayer ceci.

Voici ce que j'ai fait:

1. J'avais initialement fait une fusion avant de réaliser que j'avais ce problème et que je devais l'annuler - 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 suis passé à Unix ( :set ff=unix). Un outil comme dos2unixpourrait être utilisé au lieu de cours

3. engagé

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

   git checkout old-code-branch; git merge master

5. Les conflits ont été résolus et les fichiers étaient à nouveau DOS, donc :set ff=unixje devais quand dans VIM. (Notez que j'ai installé https://github.com/itchyny/lightline.vim qui m'a permis de voir quel est le format de fichier sur la ligne d'état VIM)

6. engagé. Tout trié!

Le problème que j'ai rencontré est que Windows ne se soucie pas de la capitalisation du nom de fichier, mais git le fait. Git a donc stocké une version inférieure et majuscule du fichier mais n'a pu en extraire qu'une.

J'ai validé toutes les modifications, puis j'ai effectué et annulé la validation. Cela a fonctionné pour moi

git add.

git commit -m "Validation aléatoire"

git reset --hard HEAD ~ 1

Normalement, dans GIT pour effacer toutes vos modifications et nouveaux fichiers, les 2 commandes suivantes devraient fonctionner très bien ( faites attention , cela supprimera tous vos nouveaux fichiers + dossiers que vous avez peut-être créés et restaurera tous vos fichiers modifiés à l'état de votre courant) valider ):

$ git clean --force -d
$ git checkout -- .

Peut-être qu'une meilleure option est parfois de simplement faire "git stash push" avec un message facultatif, comme ceci:

$ git stash push -m "not sure if i will need this later"

Cela effacera également tous vos fichiers nouveaux et modifiés, mais vous les aurez tous cachés au cas où vous souhaiteriez les restaurer. Stash dans GIT est transporté de branche en branche, vous pouvez donc les restaurer dans une autre branche, si vous le souhaitez.

En guise de remarque, si vous avez déjà mis en scène des fichiers récemment ajoutés et que vous souhaitez vous en débarrasser, cela devrait faire l'affaire:

$ git reset --hard

Si tout ce qui précède ne fonctionne pas pour vous , lisez ci-dessous ce qui a fonctionné pour moi il y a quelque temps:

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

De plus, à ce moment-là, je ne pouvais pas commander une autre branche, donc j'étais coincé sur ma branche "développer".

C'est ce que j'ai fait:

$ git log

J'ai remarqué que la nouvelle branche que j'ai créée à partir de "develop" plus tôt dans la journée montrait dans le premier message "commit", étant référencée à la fin "HEAD -> develop, origin / develop, origin / HEAD, The-branch-i-created -plus tôt-aujourd'hui ".

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

Cela 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 $ git stash list, les modifications seront cachées, et comme j'en avais peu et que je n'avais besoin d'aucune de mes cachettes, je l'ai fait $ git stash clearpour SUPPRIMER TOUTES LES CACHEES.

REMARQUE : 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 serai sûr de l'essayer la prochaine fois que je rencontrerai ce problème.

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=autole .gitattributesfichier. Cela a été mis spécifiquement parce que le propriétaire du référentiel veut 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

Puis fusionnez (ou extrayez la demande) la branche au propriétaire du référentiel.

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

git add -A
git reset --hard

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

git checkout <file>

Après avoir fermé Visual Studio, la commande a fonctionné et j'ai finalement pu appliquer mon travail à partir de la pile. Vérifiez donc toutes les applications susceptibles d'apporter des modifications à votre code, par exemple SourceTree, SmartGit, NotePad, NotePad ++ et d'autres éditeurs.

Nous étions confrontés à une situation similaire dans notre entreprise. Aucune des méthodes proposées ne nous a aidés. À la suite de la recherche, le problème a été révélé. Le fait était que dans Git, il y avait deux fichiers, dont les noms ne différaient que 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 sous Windows, les commandes suivantes ont été aidées (dans différentes séquences):

git reset --hard
git pull origin
git merge

Je l'ai résolu en éditant .git / config, en ajoutant:

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

Ensuite, je suis allé dans .git / refs / heads / name_branch et j'ai placé l'id du dernier commitenter code here

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

1. Copiez le contenu du code correct que vous souhaitez
2. Supprimez le fichier à l'origine du problème (celui que vous ne pouvez pas rétablir) de votre disque. vous devriez maintenant trouver les deux versions du même fichier marquées comme étant supprimées.
3. Validez la suppression des fichiers.
4. Créez à nouveau le fichier avec le même nom et collez le code correct que vous avez copié à l'étape 1
5. valider la création du nouveau fichier.

C'est ce qui a fonctionné pour moi.

Une solution proposée ici n'a pas fonctionné, j'ai découvert que le fichier était en fait un lien vers des caractères spéciaux:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png