Changements non marqués laissés après la réinitialisation de git -- dur

Le titre dit tout.

après git reset --hard , git status me donne des fichiers dans la section Changes not staged for commit: .

j'ai aussi essayé git reset . , git checkout -- . et git checkout-index -f -a , en vain.

alors, comment puis-je me débarrasser de ces changements non stabilisés?

cela semble ne frapper que les dossiers de projet de studio visuel. Étrange. Voir cette pâte: http://pastebin.com/eFZwPn9Z . Quel est spécial avec ces fichiers, c'est que dans .gitattributes j'ai:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

aussi, autocrlf est mis à false dans mon global .gitconfig . Peut-être que d'une certaine manière pertinente?

192
demandé sur Bugs 2012-07-08 16:19:15
la source

18 ответов

j'ai eu le même problème et il était lié au fichier .gitattributes . Cependant, le type de fichier à l'origine du problème n'était pas spécifié dans le .gitattributes .

j'ai été en mesure de résoudre le problème simplement en exécutant

git rm .gitattributes
git add -A
git reset --hard
296
répondu GameScripting 2013-11-06 20:55:25
la source

Git ne réinitialisera pas les fichiers qui ne sont pas sur le dépôt. Ainsi, vous pouvez:

$ git add .
$ git reset --hard

cela va mettre en scène tous les changements, ce qui va amener Git à être au courant de ces fichiers, puis de les réinitialiser.

si cela ne fonctionne pas, vous pouvez essayer de cacher et de laisser tomber vos changements:

$ git stash
$ git stash drop
74
répondu YuriAlbuquerque 2012-07-08 16:26:09
la source

résolu!!!

j'ai résolu ce problème en utilisant stpes

1) Supprimer chaque fichier de l'index de Git.

git rm --cached -r .

2) réécrivez l'index Git pour récupérer toutes les nouvelles fins de ligne.

git reset --hard
La Solution

faisait partie des étapes décrites sur le site de git https://help.github.com/articles/dealing-with-line-endings/

58
répondu Jacek Szybisz 2016-12-08 17:30:01
la source

j'ai eu le même problème et stash, hard reset, clean ou même tous les laisser des changements derrière. Ce qui s'est avéré être le problème était le mode de fichier x qui n'a pas été défini correctement par git. C'est un "problème connu" avec git pour windows. Les modifications locales apparaissent dans les statuts gitk et git comme ancien mode 100755 nouveau mode 100644, sans aucune différence réelle de fichier.

le correctif est d'ignorer le mode fichier:

git config core.filemode false

Plus d'informations ici

38
répondu vezenkov 2017-05-23 15:10:43
la source

OK, j'ai en quelque sorte résolu le problème.

il semble que le dossier .gitattributes , contenant:"

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

donnait l'impression que les dossiers de projet n'étaient pas archivés. Je ne sais pas pourquoi, et j'espère vraiment que quelqu'un qui connaît les méthodes de git nous donnera une belle explication.

Ma solution était de supprimer ces fichiers, et d'ajouter autocrlf = false sous [core] dans .git/config .

s'élève à exactement la même chose que la configuration précédente, car il exige que chaque dev ait autocrlf = false . J'aimerais trouver une meilleure correction.

EDIT:

j'ai commenté les lignes incriminantes, les ai décommentées et ça a marché. Ce que l' ... Je n'ai pas encore ... !

29
répondu Norswap 2012-07-08 19:20:15
la source

Cause Possible #1-Normalisation De Fin De Ligne

une situation dans laquelle cela peut se produire est lorsque le fichier en question a été vérifié dans le dépôt sans la configuration correcte pour les fins de ligne (1) résultant dans un fichier dans le dépôt avec soit les fins de ligne incorrectes, ou les fins de ligne mélangées. Pour confirmer, vérifiez que git diff n'affiche que les modifications dans les fins de ligne (celles-ci peuvent ne pas être visibles par défaut, essayez git diff | cat -v pour voir les retours de chariot comme les caractères littéraux ^M ).

par la suite, quelqu'un a probablement ajouté un .gitattributes ou modifié le paramètre core.autocrlf pour normaliser les fins de ligne (2). Basé sur la .gitattributes ou global config, Git a appliqué des modifications locales à votre copie de travail qui appliquent la normalisation de fin de ligne demandée. Malheureusement, pour une raison quelconque, git reset --hard n'annule pas ces changements de normalisation de ligne.

Solution

Les solutions de rechange dans lesquelles les fins de ligne locales sont réinitialisées ne résoudront pas le problème. Chaque fois que le fichier est "vu" par git, il va essayer et réappliquer la normalisation, le même problème.

la meilleure option est de laisser git appliquer la normalisation qu'il veut en normalisant toutes les fins de ligne dans le repo pour correspondre au .gitattributes , et en commettant ces changements -- voir essayer de fixer les fins de ligne avec git filter-branch, mais n'ayant aucune chance .

si vous voulez vraiment essayer de retourner les modifications au fichier manuellement, alors la solution la plus simple semble être d'Effacer les fichiers modifiés, puis de dire à git de les restaurer, bien que je remarque que cette solution ne semble pas fonctionner de manière cohérente 100% du temps ( AVERTISSEMENT: Ne pas exécuter ceci si vos fichiers modifiés ont des changements autres que les fins de ligne!!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

notez que, à moins que vous ne normalisiez la ligne les terminaisons dans le dépôt à un moment donné, vous continuerez à courir dans cette question.

Cause Possible #2-Cas D'Insensibilité

la deuxième cause possible est l'insensibilité de cas sur Windows ou Mac OS / X. Par exemple, dire un chemin comme le suivant existe dans le dépôt:

/foo/bar

maintenant quelqu'un sur Linux commet des fichiers dans /foo/Bar (probablement en raison d'un outil de construction ou quelque chose qui créé ce répertoire) et pousse. Sur Linux, il s'agit en fait de deux répertoires séparés:

/foo/bar/fileA
/foo/Bar/fileA

le fait de vérifier cette mise à jour sur Windows ou Mac peut entraîner une modification de fileA qui ne peut pas être réinitialisée, parce que sur chaque réinitialisation, Git sur Windows coche /foo/bar/fileA , et puis parce que Windows est insensible à la casse, remplace le contenu de fileA par /foo/Bar/fileA , ce qui entraîne leur"modification".

un autre cas peut être fichier(s) individuel (s) existant dans la mise à jour, qui, lorsqu'il est coché sur un système de fichiers insensible à la casse, se chevaucherait. Par exemple:

/foo/bar/fileA
/foo/bar/filea

Il peut y avoir d'autres situations similaires qui pourraient causer ces problèmes.

git à la casse des systèmes de fichiers devrait vraiment détecter cette situation et de montrer utile de message d'avertissement, mais il ne le fait pas (ce qui peut changer dans le futur -- voir cette discussion et les patches proposés sur le git.git liste de diffusion).

Solution

la solution est de mettre le cas des fichiers dans l'index git et le cas du système de fichiers Windows en alignement. Cela peut être fait soit sur Linux qui montrera l'état réel des choses, soit sur Windows avec un utilitaire open source très utile git-Unite . Git-Unite va appliquer les modifications de cas nécessaires à l'indice git, qui peut alors être engagé dans le repo.

(1) cela a été très probablement par Quelqu'un utilisant Windows, sans aucune définition de .gitattributes pour le fichier en question, et en utilisant le paramètre global par défaut pour core.autocrlf qui est false (voir (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line /

10
répondu Raman 2018-09-02 04:50:51
la source

une autre cause pourrait être case-insensitive file systems . Si vous avez plusieurs dossiers dans votre repo sur le même niveau dont les noms ne diffèrent que par cas, vous serez frappé par ceci. Parcourez le dépôt source en utilisant son interface web (par exemple GitHub ou VSTS) pour en être sûr.

pour plus d'informations: https://stackoverflow.com/a/2016426/67824

5
répondu Ohad Schneider 2017-05-23 15:02:46
la source

Exécuter propre "151930920 de la commande":

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd
3
répondu mrks 2016-12-14 16:09:56
la source

Vérifiez votre .gitattributes .

dans mon cas, j'ai *.js text eol=lf dans l'option it et git core.autocrlf était true .

cela m'amène à la situation où git autoconvertit les fins de ligne de mes fichiers et m'empêche de le corriger et même git reset --hard HEAD n'a rien fait.

je le fixe en commentant *.js text eol=lf dans mon .gitattributes et le décommente après lui.

on dirait que c'est magique.

3
répondu Ohar 2017-01-19 13:28:14
la source

Vous pouvez stash loin de vos modifications, puis déposez la cachette:

git stash
git stash drop
2
répondu Shahbaz 2012-07-08 16:23:35
la source

aucune de ces méthodes ne fonctionnait pour moi, la seule solution était d'atomiser l'ensemble du repo et de le cloner de nouveau. Cela inclut les cachant, réinitialisation, ajoutant ensuite la réinitialisation, clrf paramètres, casse etc. Soupir..

2
répondu John Hunt 2016-10-17 17:57:48
la source

j'ai eu le même problème. J'ai fait git reset --hard HEAD mais chaque fois que j'ai fait git status j'ai vu des fichiers modifiés.

ma solution était relativement simple. Je viens de fermer mon IDE (ici C'était Xcode) et fermer ma ligne de commande (ici c'était terminal sur mon Mac OS) et j'ai essayé à nouveau et ça a fonctionné .

pourtant, je n'ai jamais été en mesure de trouver ce qui a causé le problème.

1
répondu Honey 2016-10-11 14:18:28
la source

j'ai soulevé une question semblable concernant aussi .gitattributes , mais pour mon cas, il s'agissait de L'EPA de GitHub. Bien que ce ne soit pas exactement le scénario de L'OP, je pense qu'il offre une occasion d'illustrer ce que fait le fichier .gitattributes et pourquoi il peut conduire à des changements non stabilisés sous la forme de différences "fantômes".

Dans mon cas, le fichier était déjà dans mon référentiel, comme depuis le début des temps. Dans une commit récente, j'ai ajouté une nouvelle règle git-lfs track en utilisant un pattern qui avec le recul, c'était un peu trop large, et ça a fini par correspondre à ce fichier ancien. Je sais que je ne voulais pas changer ce fichier; je sais que je n'ai pas changé le fichier, mais maintenant c'était dans mes changements non-marqués et aucune quantité de checkouts ou de réinitialisation dur sur ce fichier allait le réparer. Pourquoi?

GitHub de l'EPA des travaux d'extension principalement en tirant parti des crochets qui git permet d'accéder via la "151900920 de fichier". En général, les entrées dans .gitattributes précisent comment les dossiers doivent être traités. Dans le cas de L'OP, il s'agissait de normaliser les fins de ligne; dans le mien, il s'agissait de savoir s'il fallait laisser L'EFT gérer le stockage des fichiers. Dans les deux cas, le fichier effectivement que git voit lors du calcul d'un git diff ne correspond pas au fichier que vous voyez lorsque vous inspectez le fichier. Par conséquent, si vous changez la façon dont un fichier est traité via le modèle .gitattributes qui correspond, il apparaîtra comme des changements non marqués dans le rapport de situation, même s'il n'y a vraiment aucun changement dans fichier.

Tout ce qui dit, ma" réponse "à la question Est que si le changement dans .gitattributes fichier est quelque chose que vous vouliez faire, vous devriez vraiment juste ajouter les changements et passer à autre chose. Sinon, modifiez le .gitattributes pour mieux représenter ce que vous voulez faire.

Références

  1. Github LFS Spécification - grande description de la façon dont ils accrochent dans le Appels de fonction clean et smudge pour remplacer votre fichier dans les objets git par un simple fichier texte avec un hachage.

  2. gitattributes Documentation - tous les détails sur ce qui est disponible pour personnaliser la façon dont git traite vos documents.

1
répondu merv 2016-11-17 23:37:37
la source

je crois qu'il y a un problème avec git pour Windows où git écrit au hasard les fins de ligne erronées sur la caisse et la seule solution est de vérifier une autre branche et de forcer git à ignorer les changements. Ensuite, vérifiez la branche sur laquelle vous voulez travailler.

git checkout master -f
git checkout <your branch>

soyez conscient que cela va rejeter tous les changements que vous pourriez avoir intentionnellement fait, alors ne faites ceci que si vous avez ce problème immédiatement après la caisse.

Edit: I ont effectivement eu de la chance la première fois. Il s'avère que j'ai été mordu à nouveau après avoir changé de branche. Il s'est avéré que les fichiers git rapportaient tels que modifiés après avoir changé les directions générales. (Apparemment parce que git n'appliquait pas uniformément la fin de ligne du CRLF aux fichiers correctement.)

j'ai mis à jour vers le dernier git pour Windows et j'espère que le problème est parti.

0
répondu mrfelis 2017-04-19 22:09:28
la source

question similaire, mais je ne suis sûr que sur la surface. Quoi qu'il en soit, il peut aider quelqu'un: ce que j'ai fait (FWIW, dans SourceTree): planqué le fichier non engagé, puis fait une réinitialisation dure.

0
répondu elder elder 2017-05-18 12:51:08
la source

comme d'autres réponses l'ont souligné, le problème est dû à la correction automatique de la fin de ligne. J'ai rencontré ce problème avec un *.les fichiers svg. J'ai utilisé svg file pour les icônes dans mon projet.

pour résoudre ce problème, j'ai fait savoir à git que les fichiers svg devraient être traités comme des fichiers binaires au lieu du texte en ajoutant la ligne ci-dessous .gitattributes

*.svg binaire

0
répondu vuamitom 2017-07-20 05:23:20
la source

si les autres réponses ne fonctionnent pas, essayer d'ajouter les fichiers, puis réinitialiser

$ git add -A
$ git reset --hard

dans mon cas, ça a aidé quand il y avait un tas de fichiers vides que git suivait.

0
répondu joshuakcockrell 2018-09-11 00:57:06
la source

dans une situation similaire. À la suite de nombreuses années de tourment avec de nombreux programmeurs qui ont été en mesure de bourrer différents codages des extrémités des lignes (. asp ,.js, .CSS. .. pas l'essence) dans un seul fichier. Il y a quelques temps refusé .gitattributes. Réglages pour repo à gauche autorclf = true et safecrlf = warn .

le dernier problème est apparu lors de la synchronisation à partir de l'archive avec différentes extrémités des lignes. Après avoir copié à partir de l'archive, dans le statut git de nombreux fichiers sont modifiés avec la note

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Conseils Comment normaliser arbre de travail les fins de ligne dans Git? aidé

git add -u

0
répondu MrSwed 2018-10-05 11:00:03
la source

Autres questions sur git git-reset