git status affiche les modifications, git checkout - ne les supprime pas

J'avais ce problème sur Windows mais je n'étais pas prêt à examiner les ramifications de l'utilisation de config --global core.autocrlf false Je n'étais pas non plus prêt à abandonner d'autres branches privées et goodies dans ma cachette et de commencer avec un clone frais. J'ai juste besoin de faire quelque chose. Maintenant.

cela a fonctionné pour moi, sur l'idée que vous avez laissé git réécrire votre répertoire de travail complètement:

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

(notez que courir juste git reset --hard n'était pas suffisant ni était une plaine rm sur les fichiers avant de les reset comme suggéré dans les commentaires à la question de départ)

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

1. remplacer le contenu de .gitattributes par une ligne unique: * binary . Cela dit à 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 est parti; si ce n'est pas le cas, vous pouvez git checkout -- <files> pour les restaurer dans la version du dépôt
3. git checkout -- .gitattributes à restaurer le fichier .gitattributes à 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: avoir des changements de filemode peut aussi avoir les mêmes symptômes. git config core.filemode false le réparera.

cela m'a rendu fou, surtout que je ne pouvais pas réparer cela sans aucune des solutions trouvées en ligne. Voici comment je l'ai résolu. Ne pouvez 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 windows. Cela a causé mon engagement initial à GLFW pour être sans la fin de la ligne appropriée.

Note: il s'agit uniquement d'un local solution. Le prochain gars clonant le repo sera toujours bloqué avec ce problème. Une solution permanente peut être trouvé ici: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository .

le programme d'Installation: Xubuntu 12.04 Repo Git avec glfw projet

problème: Impossible de réinitialiser les fichiers glfw. Ils sont toujours modifiés, 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 le supprimer dans les fichiers non tracés). git checkout -- n'a pas fonctionné, 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 ensuite supprimer la cachette:

git stash drop

a eu le même numéro deux fois! Les deux fois, j'ai caché des changements et j'ai essayé de les ramener. Ne pouvait pas pop les changements puisque j'ai beaucoup de dossier qui sont changés -- mais ils ne 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 dépôt.

lors de la diffusion du fichier, il dit j'ai supprimé toutes les lignes, puis les ajouter à nouveau.

un peu dérangeant. Je vais maintenant éviter de me cacher dans le futur..

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

Je n'ai pu corriger cela qu'en supprimant temporairement mes pensions .gitattributes file (qui définit * text=auto et *.c text ).

j'ai couru git status après avoir supprimé et les modifications ont disparu. Ils ne sont pas revenus même après .gitattributes a été remis en place.

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

certains programmes comme bash (sous linux) l'exigent aussi .les fichiers sh sont finis.

pour être sûr que cela arrive, vous pouvez utiliser gitattributes. Il fonctionne au niveau du dépôt, quelle que soit la valeur d'autcrlf.

par exemple vous peut avoir .gitattributes comme ça: * text=auto

vous pouvez également être plus spécifique par type/extension de fichier si cela a de l'importance dans votre cas.

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

Sur un mixte C#/C++/Java/Ruby/R, Windows/Linux projet c'est bien le travail. Pas de problèmes jusqu'à présent.

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

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 sur git rm --cached app.js il signe comme supprimé et dans les fichiers non tracés, je pouvais voir app.js. Mais quand j'ai essayé rm -rf app.js et peform git status encore une fois, il me montre toujours 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ée, et parce que l'app.js a été généré à partir de quelques autres fichiers js, nous avons constaté que, après chaque opération avec js fichiers (également cette application.js) grunt recréer app.js de nouveau.

il y a beaucoup de solutions ici et j'aurais peut-être dû en essayer quelques-unes avant de trouver la mienne. De toute façon ici est un plus ...

notre problème était que nous n'avions pas d'application pour les lignes terminales et le dépôt avait un mélange de DOS / Unix. Pire encore, il s'agissait en fait d'un repo open source dans cette position, et que nous avions bifurqué. La décision a été prise par ceux qui ont la propriété principale du dépôt OS de changer toutes les lignes d'extrémité à Unix et le commit a été faite qui comprenait un .gitattributes pour faire respecter les fins de ligne.

malheureusement cela a semblé causer des problèmes beaucoup comme décrit ici où une fois une fusion de code d'avant le DOS-2-Unix a été fait les fichiers seraient marqués à jamais comme modifié et ne pourrait pas être inversé.

au cours de mes recherches pour ceci je suis tombé sur - https://help.github.com/articles/dealing-with-line-endings / - si je fais face à ce problème encore une fois, je commencerais par essayer ceci.

voici ce que j'ai fait:

1. j'avais d'abord fait une fusion avant de réaliser que j'avais ce problème et que j'avais dû avorter que - git reset --hard HEAD ( j'ai couru dans un conflit de fusion. Comment puis-je annuler la fusion? )

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

3. commis

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

   git checkout old-code-branch; git merge master

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

6. commis. Tout trié!

ce problème peut également se produire quand un contributeur à la pension fonctionne sur une machine Linux, ou windows avec Cygwin et les permissions de fichiers sont changées. Git ne connaît que 755 et 644.

exemple de cette question et comment la 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 Git correctement 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. Ainsi git stocké une version inférieure et en majuscules du fichier, mais ne pouvait en vérifier qu'une.

pour moi, le problème est que Visual Studio a été ouvert en exécutant la commande

git checkout <file>

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

si vous clonez un dépôt et que vous voyez instantanément les modifications en attente, alors le dépôt est dans un état incohérent. Veuillez ne pas commenter * text=auto dans le fichier .gitattributes . Cela a été mis là spécifiquement parce que le propriétaire du dépôt veut tous les fichiers stockés de manière cohérente avec les fins de ligne LF.

comme indiqué par HankCa, en suivant les instructions sur https://help.github.com/articles/dealing-with-line-endings / is the way pour 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

fusionne ensuite (ou demande pull) la succursale au propriétaire de la pension.

rien d'autre sur cette page n'a fonctionné. Ça a finalement marché pour moi. Il n'y a pas de fichiers non tracés ou commentés.

git add -A
git reset --hard

Essayer de faire un

git checkout-f

qui devrait effacer tous les changements dans le rapport local de travail actuel

j'ai fait tous les changements et ensuite j'ai fait et défait sur le commit. Cela a fonctionné pour moi

git add .

git commit -m "Aléatoire commettre"

git reset --hard HEAD~1

nous avons fait face à une situation similaire dans notre entreprise. Aucune des méthodes proposées ne nous a pas aidé. La recherche a révélé le problème. la chose était que dans Git il y avait deux dossiers, dont les noms différaient seulement dans le registre des symboles. Unix-systems les voyait comme deux fichiers différents, mais Windows devenait fou. pour résoudre le problème, nous avons supprimé un des fichiers du serveur. Après cela, aux dépôts locaux sur Windows a aidé le les commandes suivantes (dans des séquences différentes):

git reset --hard
git pull origin
git merge

j'ai rencontré ce problème quelques fois auparavant. Je développe actuellement sur Windows 10 machine fourni par mon employeur. Aujourd'hui, ce comportement particulier de git a été causé par la création d'une nouvelle branche à partir de ma branche "développer". Pour une raison quelconque, après que je suis revenu à la branche" develop", certains fichiers apparemment aléatoires ont persisté et se sont révélés comme "modifiés" dans "git status".

aussi, à ce point je ne pouvais pas vérifier une autre branche, donc j'ai été coincé sur mon " développer" direction.

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 aujourd'hui apparaissait dans le premier message" commit", étant référencé à la fin "HEAD -> develop, origin/develop, origin/HEAD, The-branch-i-created-earlier-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 étaient encore

$ 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 montrera des modifications cachées, et comme j'en avais peu et que je n'avais besoin d'aucune de mes caches, j'ai fait $ git stash clear pour supprimer 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 peut avoir fonctionné aussi bien, je ne manquerai pas d'essayer prochaine fois que je rencontre ce problème.