Modifications non mises en place laissées après la réinitialisation de git --hard
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 mis en scène?
Cela semble toucher uniquement les fichiers de projet Visual Studio. Bizarre. Voir cette pâte: http://Pastebin.com/eFZwPn9Z . Ce qui est spécial avec ces fichiers, c’est que dans .gitattributes j’ai:
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
De plus, autocrlf est défini sur false dans mon .gitconfig global. Cela pourrait-il être pertinent?
Ok, j'ai en quelque sorte résolu le problème.
Il semblait que le fichier .gitattributes, contenant:
*.sln eol=crlf
*.vcproj eol=crlf
*.vcxproj* eol=crlf
fait en sorte que les fichiers du projet apparaissent non staged Je ne comprends pas pourquoi, et j'espère vraiment que quelqu'un au courant des méthodes d'idiot nous donnera une bonne explication.
Mon correctif consistait à supprimer ces fichiers et à ajouter autocrlf = false sous [core] dans .git/config.
Cela ne revient pas exactement à la même chose que la configuration précédente, car chaque développeur devait avoir autocrlf = false. J'aimerais trouver une meilleure solution.
MODIFIER:
J'ai commenté les lignes incriminantes, les commenté et cela a fonctionné. Qu'est-ce que ... je ne même pas ...!
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 pu résoudre le problème en exécutant simplement
git rm .gitattributes
git add -A
git reset --hard
Git ne réinitialisera pas les fichiers qui ne sont pas dans le référentiel. Afin que vous puissiez:
$ git add .
$ git reset --hard
Cela mettra en place toutes les modifications, ce qui fera que Git sera au courant de ces fichiers, puis les réinitialisera.
Si cela ne fonctionne pas, vous pouvez essayer de stocker et de supprimer vos modifications:
$ git stash
$ git stash drop
RÉSOLU !!!
J'ai résolu ce problème en utilisant les stpes suivants
1) Supprimez tous les fichiers 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 git https://help.github.com/articles/dealing-with-line-endings/
Si vous utilisez Git pour Windows, c'est probablement votre problème
J'ai eu le même problème et stash, réinitialisation matérielle, nettoyer ou même tous laissaient encore des changements derrière. Le problème s’est avéré que le mode de fichier x n’était pas correctement défini par git. Ceci est un "problème connu" avec git pour Windows. Les modifications locales indiquent les statuts gitk et git comme étant l'ancien mode 100755 et le nouveau mode 100644, sans aucune différence de fichier.
Le correctif consiste à ignorer le mode de fichier:
git config core.filemode false
Cause possible n ° 1 - Normalisation de fin de ligne
Cela peut arriver lorsque le fichier en question a été archivé dans le référentiel sans la configuration correcte pour les fins de ligne (1), ce qui entraîne la création d'un fichier dans le référentiel avec des fins de ligne incorrectes ou des fins de ligne mixtes. Pour confirmer, vérifiez que git diff n'affiche que les modifications de fin de ligne (celles-ci peuvent ne pas être visibles par défaut. Essayez git diff | cat -v pour afficher les retours chariot sous la forme de caractères ^M littéraux).
Par la suite, quelqu'un a probablement ajouté un .gitattributes ou modifié le paramètre core.autocrlf pour normaliser les fins de ligne (2). Sur la base du .gitattributes ou de la configuration globale, Git a appliqué à votre copie de travail des modifications locales qui appliquaient la normalisation de fin de ligne demandée. Malheureusement, pour une raison quelconque, git reset --hard n'annule pas ces modifications de la normalisation de ligne.
Solution
Les solutions de contournement dans lesquelles les fins de ligne locales sont réinitialisées ne résolvent pas le problème. Chaque fois que le fichier est "vu" par git, il essaiera de réappliquer la normalisation, ce qui entraînera le même problème.
La meilleure option est de laisser git appliquer la normalisation souhaitée en normalisant toutes les fins de ligne du référentiel afin qu'elles correspondent au .gitattributes, puis en validant ces modifications - voir Essayer de réparer les fins de ligne avec git filter-branch, mais en ayant pas de chance .
Si vous voulez vraiment essayer de revenir manuellement sur les modifications apportées au fichier, la solution la plus simple semble être d'effacer les fichiers modifiés, puis de demander à git de les restaurer, bien que cette solution ne semble pas fonctionner de manière cohérente à 100%. l'heure (ATTENTION: NE PAS exécuter ceci si vos fichiers modifiés ont des modifications autres que les fins de ligne !!):
git status --porcelain | grep "^ M" | cut -c4- | xargs rm
git checkout -- .
Notez que, sauf si vous normalisez les fins de ligne dans le référentiel à un moment donné, vous continuerez à vous heurter à ce problème.
Cause possible n ° 2 - Insensibilité à la casse
La deuxième cause possible est l’insensibilité à la casse sous Windows ou Mac OS/X. Par exemple, supposons qu'un chemin semblable au suivant existe dans le référentiel:
/foo/bar
Désormais, quelqu'un sous Linux valide les fichiers dans /foo/Bar (probablement à cause d'un outil de construction ou de quelque chose qui a créé ce répertoire) et les envoie. Sous Linux, il s’agit en réalité de deux répertoires distincts:
/foo/bar/fileA
/foo/Bar/fileA
La vérification de ce référentiel sous Windows ou Mac peut entraîner une modification de la variable fileA qui ne peut pas être réinitialisée, car à chaque réinitialisation, git sous Windows désactive le code /foo/bar/fileA, puis parce que Windows ne respecte pas la casse, écrase le contenu de fileA avec /foo/Bar/fileA, ce qui entraîne leur suppression. "modifié".
Un autre cas peut être un ou plusieurs fichiers individuels existant dans le référentiel, qui, une fois extraits sur un système de fichiers ne tenant pas compte de la casse, se chevauchent. Par exemple:
/foo/bar/fileA
/foo/bar/filea
Il peut y avoir d'autres situations similaires qui pourraient causer de tels problèmes.
les systèmes de fichiers insensibles à la casse devraient vraiment détecter cette situation et afficher un message d’avertissement utile, mais ce n’est actuellement pas le cas (cela pourrait changer à l’avenir - voir cette discussion et les correctifs proposés dans la liste de diffusion git.git) .
Solution
La solution consiste à aligner la casse des fichiers de l'index git et celle du système de fichiers Windows. Cela peut être fait soit sur Linux qui montrera le véritable état des choses, OR sur Windows avec un utilitaire open source très utile Git-Unite . Git-Unite appliquera les modifications de cas nécessaires à l'index git, qui pourra ensuite être appliqué au référentiel.
(1) Cela était probablement dû à une personne utilisant Windows, sans définition de .gitattributes pour le fichier en question et 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/
Une autre cause à cela pourrait être systèmes de fichiers insensibles à la casse. Si vous avez plusieurs dossiers dans votre référentiel au même niveau dont les noms ne diffèrent que par cas, vous serez touché par cela. Parcourez le référentiel source à l'aide de son interface Web (par exemple, GitHub ou VSTS) pour vous en assurer.
Pour plus d'informations: https://stackoverflow.com/a/2016426/67824
Vérifiez votre .gitattributes.
Dans mon cas, j'ai *.js text eol=lf et l'option git core.autocrlf était true.
Cela m’amène à la situation où git convertit automatiquement les fins de ligne de mes fichiers et m’empêche de le réparer et que même git reset --hard HEAD ne fait rien.
Je le répare avec commenter *.js text eol=lf dans mon .gitattributes et le commente après.
On dirait que c'est juste de la magie.
Exécuter nettoyer commande:
# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)
git clean -fd
Si les autres réponses ne fonctionnent pas, essayez d’ajouter les fichiers, puis réinitialisez
$ git add -A
$ git reset --hard
Dans mon cas, cela a aidé quand il y avait un tas de fichiers vides que git suivait.
Aucune de ces méthodes ne fonctionnait pour moi, la seule solution était de décomposer le référentiel en entier et de le cloner à nouveau. Cela inclut le stockage, la réinitialisation, l’ajout, puis la réinitialisation, les paramètres de verrouillage, la sensibilité à la casse, etc.
Vous pouvez stash quitter vos modifications, puis déposez la réserve:
git stash
git stash drop
J'ai rencontré un problème similaire impliquant également .gitattributes, mais pour mon cas, il s'agissait de LFS de GitHub. Bien que ce ne soit pas exactement le scénario du PO, je pense que cela fournit une occasion d’illustrer le rôle du fichier .gitattributes et la raison pour laquelle il peut entraîner des modifications non mises en scène sous la forme de différences "fantômes".
Dans mon cas, un fichier était déjà dans mon référentiel, comme depuis le début des temps. Dans un commit récent, j’ai ajouté une nouvelle règle git-lfs track en utilisant un motif qui était un peu trop rétrospectivement, et qui a fini par correspondre à cet ancien fichier. Je sais que je ne voulais pas changer ce fichier; Je sais que je n’ai pas modifié le fichier, mais c’était maintenant dans mes modifications non mises en scène et qu’aucune quantité d’exportations ou de réinitialisations matérielles de ce fichier n’allait résoudre le problème. Pourquoi?
L'extension GitHub LFS fonctionne principalement en exploitant les points d'ancrage que git fournit via le fichier .gitattributes. Généralement, les entrées dans .gitattributes spécifient comment les fichiers correspondants doivent être traités. Dans le cas du PO, il s’agissait de normaliser les fins de ligne; dans le mien, il s'agissait de laisser LFS gérer le stockage de fichiers. Dans les deux cas, le fichier que git voit lors du calcul d'un git diff ne correspond pas au fichier que vous voyez lors de l'inspection du fichier. Par conséquent, si vous modifiez la façon dont un fichier est traité via le modèle .gitattributes qui lui correspond, il apparaîtra comme des modifications non mises en scène dans le rapport d'état, même s'il n'y a vraiment aucune modification dans le fichier.
Cela dit, ma "réponse" à la question est que si le changement de fichier .gitattributes est quelque chose que vous souhaitiez faire, vous devriez vraiment juste ajouter les modifications et passer à autre chose. Sinon, modifiez le .gitattributes pour mieux représenter ce que vous voulez faire.
Références
Spécification GitHub LFS - Description détaillée de la manière dont ils se connectent aux appels de fonction
cleanetsmudgepour remplacer votre fichier dans les objetsgitpar un simple fichier texte avec un hachage.gitattributes Documentation - Tous les détails sur ce qui est disponible pour personnaliser la façon dont
gittraite vos documents.
Je crois qu’il existe un problème avec git pour Windows dans lequel git écrit de façon aléatoire les fins de ligne erronées lors du paiement et la seule solution de contournement consiste à extraire une autre branche et de forcer git à ignorer les modifications. Ensuite, vérifiez la branche sur laquelle vous voulez réellement travailler.
git checkout master -f
git checkout <your branch>
Sachez que cela annulera toutes les modifications que vous auriez intentionnellement apportées. Ne le faites donc que si vous rencontrez ce problème immédiatement après le paiement.
Edit: J'ai peut-être eu de la chance la première fois. Il se trouve que je me suis encore mordu après avoir changé de branche. Il s'est avéré que les fichiers que git signalait comme modifiés après le changement de branche changeaient. (Apparemment, parce que git n'appliquait pas correctement la ligne CRLF se terminant correctement sur les fichiers.)
J'ai mis à jour le dernier git pour Windows et j'espère que le problème aura disparu.
Comme d'autres réponses l'ont souligné, le problème vient de la correction automatique en fin de ligne. J'ai rencontré ce problème avec les fichiers * .svg. J'ai utilisé le fichier svg pour les icônes de mon projet.
Pour résoudre ce problème, j'ai informé git que les fichiers svg devraient être traités comme des fichiers binaires au lieu de texte en ajoutant la ligne ci-dessous à.
binaire * .svg
J'ai eu le même problème. J'ai fait git reset --hard HEAD mais toujours à chaque fois git status, je voyais des fichiers modifiés.
Ma solution était relativement simple. Je viens de fermer mon IDE (ici, c’était Xcode) et de fermer ma ligne de commande (ici, c’était un terminal sur Mac OS) et je l’essayai encore et cela fonctionna.
Pourtant, je n'ai jamais pu trouver l'origine du problème.
Problème similaire, même si je suis sûr que sur la surface. Quoi qu'il en soit, cela peut aider quelqu'un: ce que j'ai fait (FWIW, dans SourceTree): a caché le fichier non validé, puis a effectué une réinitialisation matérielle.
Une autre possibilité que j'ai rencontrée était qu'un des paquets dans le référentiel finissait avec un HEAD détaché. Si aucune des réponses ici ne vous aide et que vous rencontrez un message d’état git comme celui-ci, vous risquez de rencontrer le même problème:
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: path/to/package (new commits)
En allant dans le dossier path/to/package, un git status devrait donner le résultat suivant:
HEAD detached at 7515f05
Et la commande suivante devrait alors résoudre le problème, où master devrait être remplacé par votre branche locale:
git checkout master
Et vous recevrez un message indiquant que votre branche locale effectuera un certain nombre de commits derrière la branche distante. git pull et vous devriez être sorti du bois!
Dans une situation similaire. À la suite de nombreuses années de tourments avec de nombreux programmeurs qui ont été en mesure de stocker différents codages des fins de lignes (.asp, .js, .css ... pas l’essence) dans un seul fichier. Il y a quelque temps, a refusé .gitattributes. Les paramètres de repo laissaient autorclf = true etsafecrlf = warn.
Le dernier problème est survenu lors de la synchronisation à partir de l'archive avec différentes extrémités de lignes. Après la copie de l'archive, dans l'état 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 de Comment normaliser les fins de ligne d'arbre de travail dans Git? aidé
git add -u