Changements non planifiés après la réinitialisation de git –hard

Le titre dit tout.

Après git reset --hard , l’ 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 impromptus?

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 .gitatsortingbutes j’ai:

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

autocrlf est également défini sur false dans mon .gitconfig global. Est-ce que cela pourrait être pertinent?

J’ai eu le même problème et il était lié au fichier .gitatsortingbutes . Toutefois, le type de fichier à l’origine du problème n’a pas été spécifié dans les .gitatsortingbutes .

J’ai pu résoudre le problème en exécutant simplement

 git rm .gitatsortingbutes git add -A git reset --hard 

Git ne réinitialisera pas les fichiers qui ne sont pas sur le référentiel. Afin que vous puissiez:

 $ git add . $ git reset --hard 

Cela mettra en scène tous les changements, ce qui entraînera Git à prendre connaissance de ces fichiers, puis à les réinitialiser.

Si cela ne fonctionne pas, vous pouvez essayer de cacher vos modifications:

 $ git stash $ git stash drop 

RÉSOLU!!!

J’ai résolu ce problème en utilisant les stpes suivants

1) Retirez tous les fichiers de l’index de Git.

 git rm --cached -r . 

2) Réécrivez l’index Git pour saisir 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/

J’ai eu le même problème et le cache, la réinitialisation matérielle, le nettoyage ou même tous laissaient encore des modifications. Ce qui s’est avéré être le problème était le mode de fichier x qui n’était pas correctement défini par git. Ceci est un “problème connu” avec git pour windows. Les modifications locales apparaissent dans l’état gitk et git en tant que l’ancien mode 100755 nouveau mode 100644, sans aucune différence de fichier réelle.

La solution consiste à ignorer le mode fichier:

 git config core.filemode false 

Plus d’infos ici

Ok, j’ai en quelque sorte résolu le problème.

Il semblait que le fichier .gitatsortingbutes , contenant:

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

fait apparaître les fichiers du projet non mis en scène. Je ne sais pas pourquoi, et j’espère vraiment que quelqu’un au courant des manières de git nous donnera une bonne explication.

Mon correctif était de supprimer ces fichiers, et d’append autocrlf = false sous [core] dans .git/config .

Cela ne correspond pas exactement à la configuration précédente, car chaque développeur doit avoir autocrlf = false . J’aimerais trouver une meilleure solution.

MODIFIER:

J’ai commenté les lignes incriminantes, les commenter et cela a fonctionné. Qu’est-ce que … Je n’ai même pas …!

Cause possible n ° 1 – Normalisation de fin de ligne

Une situation dans laquelle cela peut se produire est lorsque le fichier en question a été archivé dans le référentiel sans la configuration correcte pour les fins de ligne (1) résultant en un fichier dans le référentiel avec les fins de ligne incorrectes ou les fins de ligne mixtes. Pour confirmer, vérifiez que git diff affiche uniquement les changements de fin de ligne (ceux-ci peuvent ne pas être visibles par défaut, essayez git diff | cat -v pour voir les retours chariot comme des caractères ^M littéraux).

Par la suite, quelqu’un a probablement ajouté un .gitatsortingbutes ou modifié le paramètre core.autocrlf pour normaliser les fins de ligne (2). Sur la .gitatsortingbutes la configuration .gitatsortingbutes ou globale, Git a appliqué des modifications locales à votre copie de travail pour appliquer la normalisation de fin de ligne demandée. Malheureusement, pour une raison quelconque, git reset --hard ne git reset --hard pas ces modifications de la normalisation des lignes.

Solution

Les solutions de contournement 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 de réappliquer la normalisation, ce qui entraîne le même problème.

La meilleure option consiste à laisser git appliquer la normalisation .gitatsortingbutes en normalisant toutes les fins de ligne dans le .gitatsortingbutes pour .gitatsortingbutes correspondent aux .gitatsortingbutes et en .gitatsortingbutes ces modifications – voir Essayer de corriger les fins de ligne avec git filter-branch, mais sans la chance

Si vous voulez vraiment essayer de rétablir manuellement les modifications du fichier, la solution la plus simple semble être d’effacer les fichiers modifiés, puis de dire à Git de les restaurer, même si je constate que cette solution ne semble pas fonctionner à 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 si vous ne normalisez pas les fins de ligne dans le référentiel à un moment donné, vous continuerez à rencontrer ce problème.

Cause possible n ° 2 – Insensibilité au cas

La deuxième cause possible est l’insensibilité à la casse sous Windows ou Mac OS / X. Par exemple, disons qu’un chemin comme celui-ci existe dans le référentiel:

/foo/bar

Maintenant, 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 pousse. Sous Linux, il s’agit en fait de deux répertoires distincts:

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

La vérification de ce repository sur Windows ou Mac peut entraîner une modification du fileA qui ne peut pas être réinitialisé, car à chaque réinitialisation, git sous Windows extrait /foo/bar/fileA , et parce que Windows est insensible à la fileA /foo/Bar/fileA , entraînant leur “modification”.

Un autre cas peut être un fichier individuel existant dans le référentiel qui, une fois extrait 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 de tels problèmes.

git sur les systèmes de fichiers insensibles à la casse devrait vraiment détecter cette situation et afficher un message d’avertissement utile, mais ce n’est pas le cas actuellement (cela pourrait changer dans le futur – voir la liste de diffusion git.git).

Solution

La solution consiste à aligner la casse des fichiers de l’index git et le cas du système de fichiers Windows. Cela peut être fait soit sur Linux qui montrera le véritable état des choses, soit 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 affecté au repository.

(1) Cela a probablement été le cas pour une personne utilisant Windows, sans aucune définition .gitatsortingbutes 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/

Une autre cause pourrait être des systèmes de fichiers insensibles à la casse . Si vous avez plusieurs dossiers dans votre repo au même niveau, dont les noms diffèrent seulement 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

Exécutez la commande clean :

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

Vérifiez vos .gitatsortingbutes .

Dans mon cas, j’ai *.js text eol=lf dedans et l’option git core.autocrlf était true .

Cela m’amène à la situation où git git reset --hard HEAD fins de ligne de mes fichiers et m’empêche de le réparer et même de git reset --hard HEAD rien fait.

Je *.js text eol=lf problème en commentant *.js text eol=lf dans mes .gitatsortingbutes et je le .gitatsortingbutes après.

On dirait que c’est juste de la magie.

Vous pouvez stash vos modifications, puis laisser tomber la réserve:

 git stash git stash drop 

Aucune de ces méthodes n’a fonctionné pour moi, la seule solution étant de détruire l’ensemble du repo et de le re-cloner. Cela comprend le stockage, la réinitialisation, l’ajout, la réinitialisation, les parameters clrf, la sensibilité à la casse, etc.

J’ai eu le même problème. J’ai git reset --hard HEAD mais à chaque fois que je faisais le git status je voyais certains 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 le terminal sur mon Mac OS) et de réessayer et ça a fonctionné.

Pourtant, je n’ai jamais pu trouver l’origine du problème.

J’ai rencontré un problème similaire impliquant également .gitatsortingbutes , mais dans mon cas, il s’agissait de LFS de GitHub. Bien que ce ne soit pas exactement le scénario de l’OP, je pense qu’il fournit une opportunité d’illustrer ce que fait le fichier .gitatsortingbutes et pourquoi il peut entraîner des changements non structurés 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. Lors d’une récente validation, j’ai ajouté une nouvelle règle de git-lfs track utilisant un motif un peu trop rétroréfléchissant et finissant par correspondre à cet ancien fichier. Je sais que je ne voulais pas changer ce fichier; Je sais que je n’ai pas changé le fichier, mais maintenant, il était dans mes changements non mis en scène et aucun montant de vérifications ou de réinitialisations matérielles sur ce fichier n’allait résoudre ce problème. Pourquoi?

L’extension GitHub LFS fonctionne principalement en exploitant les hooks auxquels git fournit l’access via le fichier .gitatsortingbutes . Généralement, les entrées dans .gitatsortingbutes 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 des fichiers. Dans les deux cas, le fichier réellement détecté par git lors du calcul d’une git diff ne correspond pas au fichier que vous voyez lorsque vous inspectez le fichier. Par conséquent, si vous modifiez la façon dont un fichier est traité via le modèle .gitatsortingbutes qui lui correspond, il apparaîtra comme des modifications non planifiées dans le rapport d’état, même s’il n’y a pas vraiment de changement dans le fichier.

Cela dit, ma “réponse” à la question est que si vous vouliez .gitatsortingbutes fichier .gitatsortingbutes , vous devriez simplement append les modifications et continuer. Sinon, .gitatsortingbutes les .gitatsortingbutes pour mieux représenter ce que vous voulez faire.

Les références

  1. Spécification GitHub LFS – Excellente description de la façon dont ils se connectent aux appels de la fonction clean et smudge pour remplacer votre fichier dans les objects git par un simple fichier texte avec un hachage.

  2. Documentation gitatsortingbutes – Tous les détails sur ce qui est disponible pour personnaliser la façon dont git traite vos documents.

Je pense qu’il y a un problème avec git pour Windows où git écrit aléatoirement les terminaisons de ligne incorrectes lors de l’extraction et que la seule solution consiste à extraire une autre twig et à forcer git à ignorer les modifications. Ensuite, vérifiez la twig sur laquelle vous souhaitez travailler.

 git checkout master -f git checkout  

Sachez que cela écartera toute modification que vous pourriez avoir faite intentionnellement, alors ne le faites que si vous avez ce problème immédiatement après la vérification.

Edit: J’ai peut-être eu de la chance la première fois. Il s’est avéré que je me suis retrouvé un peu après avoir changé de twig. Il s’est avéré que les fichiers git étaient modifiés après modification des twigs. (Apparemment, parce que git n’appliquait pas systématiquement la fin de ligne CRLF aux fichiers correctement.)

J’ai mis à jour vers le dernier git pour Windows et j’espère que le problème a disparu.

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): stocké le fichier non validé, puis fait une réinitialisation matérielle.

Comme d’autres réponses l’ont souligné, le problème est dû à la correction automatique de fin de ligne. J’ai rencontré ce problème avec les fichiers * .svg. J’ai utilisé un fichier svg pour les icons dans mon projet.

Pour résoudre ce problème, je dois savoir que les fichiers svg doivent être traités comme des fichiers binarys plutôt que du texte en ajoutant la ligne ci-dessous à .gitatsortingbutes.

* .svg binary