le statut de git montre les modifications, git checkout - <fichier> ne les supprime pas
Je souhaite supprimer toutes les modifications apportées à ma copie de travail.
Lancer git status montre 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 comportement:
Normalisation de fin de ligne
J'ai eu ce genre de problèmes aussi. Cela revient à convertir automatiquement crlf en lf. Cela est généralement dû à la terminaison de lignes mélangées dans un seul fichier. Le fichier est normalisé dans l'index, mais lorsque git le dénormalise à nouveau pour le comparer au fichier dans l'arbre de travail, le résultat est différent.
Mais si vous souhaitez 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 .gitattribute files. De cette manière, vous pouvez vous assurer que toutes les personnes utilisant le référentiel utilisent les mêmes règles de normalisation, en évitant que des fins de ligne mixtes ne pénètrent 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 serait effectuée.
Le git pages de manuel dites ceci:
La conversion CRLF a une légère chance de corrompre les données. autocrlf = volonté vraie convertir CRLF en LF pendant la validation et LF à CRLF lors du paiement. Un fichier qui contient un mélange de LF et de CRLF avant que le commit ne puisse être recréé par git. Pour les fichiers texte, c'est le bonne chose à faire: il corrige la ligne terminaisons telles que nous n’avons que la ligne LF terminaisons dans le référentiel. Mais pour fichiers binaires accidentellement classé comme texte, la conversion peut données corrompues.
Systèmes de fichiers insensibles à la casse
Sur les systèmes de fichiers ne faisant pas la distinction entre les majuscules et les minuscules, lorsque le même nom de fichier avec une casse différente se trouve dans le référentiel, git essaie de vérifier les deux, mais un seul aboutit 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 ne tenant pas compte de la casse, mais dans la plupart des cas, cela n’est pas réalisable, 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 conséquences de l'utilisation de config --global core.autocrlf false. Je n'étais pas prêt non plus à abandonner d'autres branches privées et autres produits dans ma réserve 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 le fait d'exécuter uniquement git reset --hard n'était pas suffisant, pas plus qu'une simple rm sur les fichiers précédant reset, comme le suggèrent les commentaires de la question d'origine.)
Une autre solution qui peut fonctionner pour les gens, car aucune des options de texte ne fonctionnait pour moi:
- Remplacez le contenu de
.gitattributespar une seule ligne:* binary. Cela indique à git de traiter chaque fichier comme un fichier binaire avec lequel il ne peut rien faire. - Vérifiez que le message pour les fichiers incriminés est parti; Si ce n'est pas le cas, vous pouvez utiliser
git checkout -- <files>pour les restaurer dans la version du référentiel git checkout -- .gitattributespour restaurer le fichier.gitattributesà son état initial- Vérifiez que les fichiers ne sont toujours pas marqués comme modifiés.
Pour les futures personnes ayant ce problème: Avoir des changements de filemode peut aussi avoir les mêmes symptômes. git config core.filemode false va le réparer.
Cela m’a rendu fou, surtout que je ne pouvais pas résoudre ce problème sans l’une 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 se faisait sans conversion automatique de ligne sous Windows. Cela a eu pour conséquence que mon engagement initial auprès de GLFW était sans la fin de ligne appropriée.
Remarque: il ne s'agit que d'une solution locale. Le prochain gars clonant le repo sera toujours coincé avec ce problème. Une solution permanente peut être trouvé ici: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a- repository .
Configuration: Xubuntu 12.04 Git repo avec le 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 .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 (impossible de le supprimer dans des fichiers non suivis). git checkout - n'a pas fonctionné, pas plus que les suggestions de 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, j'ai caché certaines modifications puis essayé de les récupérer. Les modifications ne sont pas apparues car de nombreux fichiers 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.
Lorsque je diffère le fichier, cela signifie que j'ai supprimé toutes les lignes, puis que je les ai ajoutées à nouveau.
Un peu dérangeant. Je vais maintenant éviter de me cacher à l'avenir ..
La seule solution est de cloner un nouveau référentiel et de recommencer. (Fait la dernière fois)
Je n'ai pu résoudre ce problème qu'en supprimant temporairement le fichier .gitattributes de mon référentiel (qui définit * 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 que .gitattributes ait été remis en place.
Il y a beaucoup de solutions ici et j'aurais peut-être dû en essayer quelques unes avant de proposer la mienne. Quoi qu'il en soit voici un de plus ...
Notre problème était que nous n'avions aucune application pour les lignes de fond et que le référentiel comprenait un mélange de DOS/Unix. Le pire, c’était qu’il s’agissait en réalité d’une opération de mise en pension à source ouverte dans cette position, et que nous avions définie. Les détenteurs principaux du référentiel du système d'exploitation ont pris la décision de modifier toutes les lignes de fin en Unix et la validation a été effectuée avec un .gitattributes pour appliquer les fins de ligne.
Malheureusement, cela semblait causer des problèmes similaires à ceux décrits ici: une fois la fusion de code antérieure à DOS-2-Unix effectuée, les fichiers étaient toujours marqués comme modifiés et ne pouvaient pas être annulés.
Au cours de mes recherches, je suis tombé sur - https://help.github.com/articles/dealing-with-line-endings/ - Si je suis à nouveau confronté à ce problème, je commencerais par l'essayer. .
Voici ce que j'ai fait:
J'avais initialement fait une fusion avant de réaliser que j'avais ce problème et que je devais abandonner cela -
git reset --hard HEAD( J'ai rencontré un conflit de fusion. Comment puis-je annuler la fusion? )J'ai ouvert les fichiers en question dans VIM et suis passé à Unix (
:set ff=unix). Un outil commedos2unixpourrait être utilisé à la placeengagé
fusionné la
masterdans (le maître a les modifications de DOS-2-Unix)git checkout old-code-branch; git merge masterLes conflits résolus et les fichiers étant de nouveau DOS, nous avons donc dû
:set ff=unixdans VIM. (Remarque: j'ai installé https://github.com/itchyny/lightline.vim , ce qui m'a permis de voir le format du fichier sur le statut VIM.)- engagé. Tous triés!
Avoir des fins de ligne cohérentes est une bonne chose. Par exemple, cela ne déclenchera pas de fusions inutiles, même triviales. 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 LF.
Pour vous assurer que cela se produit, vous pouvez utiliser gitattributes. Cela fonctionne au niveau du référentiel quelle que soit la valeur de autcrlf.
Par exemple, vous pouvez avoir des .gitattributes 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 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 aussi 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.js il signe comme supprimé et dans les fichiers non suivis je pouvais voir app.js. Mais quand j'ai essayé rm -rf app.js et peform git status à nouveau, il me montre toujours le fichier en mode «non suivi».
Après quelques essais avec un collègue, nous avons découvert que cela avait été causé par Grunt!
Comme la Grunt a été activée et 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éait app.js à nouveau.
Ce problème peut également se produire lorsqu'un contributeur au référentiel fonctionne sur une machine Linux ou lorsque des 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 rechercher:
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 avez correctement configuré git en utilisant
git config --global core.filemode false
Pour moi, le problème était que Visual Studio était ouvert lors de l'exécution de la commande
git checkout <file>
Après la fermeture de Visual Studio, la commande a fonctionné et je pouvais enfin appliquer mon travail à partir de la pile. Vérifiez donc toutes les applications susceptibles d’apporter des modifications à votre code, par exemple, SourceTree, SmartGit, Bloc-notes, Bloc-notes ++ et autres éditeurs.
Si vous clonez un référentiel et que vous 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 .gitattributes. Cela a été mis là 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 l'a déclaré HankCa, suivre les instructions sur https://help.github.com/articles/dealing-with-line-endings/ est le moyen d'aller 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 tirez sur demande) la branche vers le propriétaire du référentiel.
Le problème que j'ai rencontré est que Windows ne se soucie pas de la capitalisation du fichier, mais git. Donc, git a stocké une version inférieure et majuscule du fichier mais n'a pu en extraire qu'une.
Nous avons fait face à une situation similaire dans notre entreprise. Aucune des méthodes proposées ne nous a pas aidés. À 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 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 du serveur. Après cela, dans les référentiels locaux sous Windows, les commandes suivantes (dans différentes séquences) ont été aidées:
git reset --hard
git pull Origin
git merge
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 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 "develop", certains fichiers apparemment aléatoires ont persisté et sont apparus comme "modifiés" dans "statut git".
De plus, à ce moment-là, je ne pouvais pas commander une autre branche, donc j'étais bloqué sur ma branche "develop".
C'est ce que j'ai fait:
$ git log
J'ai remarqué que la nouvelle branche que j'avais créée à partir de "develop" aujourd'hui apparaissait dans le premier message "commit", référencée à la fin "HEAD -> develop, Origin/develop, Origin/HEAD, The-branch-i -created-early-today ".
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 je l’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 affichera les modifications cachées, et comme j'en possédais peu et que je n'avais besoin d'aucune de mes cachettes, j'ai $ git stash clear pour SUPPRIMER TOUS LES STASHES.
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 fonctionné aussi, je ne manquerai pas de l'essayer la prochaine fois que je rencontrerai ce problème.
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 ai placé l'ID du dernier commitenter code here
Essayez de faire un
git checkout -f
Cela devrait effacer tous les changements dans le dépôt local de travail actuel
J'ai engagé toutes les modifications, puis j'ai annulé et exécuté le commit ..___ Cela a fonctionné pour moi
git add.
git commit -m "Commutation aléatoire"
réinitialiser git - hard HEAD ~ 1
Je l'ai résolu de cette façon:
- Copiez le contenu du code correct que vous voulez
- 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.
- Commettez la suppression des fichiers.
- Créez à nouveau le fichier avec le même nom et collez le code correct que vous avez copié à l'étape 1.
- commettre la création du nouveau fichier.
C'est ce qui a fonctionné pour moi.
Rien d'autre sur cette page n'a fonctionné. Cela a finalement fonctionné pour moi. Ne pas afficher les fichiers non suivis ou validés.
git add -A
git reset --hard