Modifications non gérées laissées après git reset --hard

Question

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

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

Alors, comment puis-je me débarrasser de ces changements non gérés ?

Cela semble toucher uniquement les fichiers de projet Visual Studio. C'est bizarre. Voir ce collage : 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

Aussi, autocrlf est définie comme fausse dans mon système global .gitconfig . Cela pourrait-il être pertinent ?

Answer 1

Cause possible n°1 - Normalisation de la fin de la ligne

Cela peut se produire lorsque le fichier en question a été archivé dans le référentiel sans la configuration correcte des fins de ligne (1), ce qui donne 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 ne montre que les changements dans les fins de ligne (ceux-ci peuvent ne pas être visibles par défaut, essayez git diff | cat -v pour voir les retours de chariot comme littéraux ^M caractères).

Par la suite, quelqu'un a probablement ajouté un .gitattributes ou modifié le core.autocrlf pour normaliser les fins de ligne (2). Sur la base de la .gitattributes ou la configuration globale, Git a appliqué des changements locaux à 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 des lignes.

Solution

Les solutions de contournement dans lesquelles les terminaisons de lignes locales sont réinitialisées ne résoudront pas le problème. Chaque fois que le fichier est "vu" par git, il essaie de réappliquer la normalisation, ce qui entraîne le même problème.

La meilleure option est de laisser git appliquer la normalisation qu'il souhaite en normalisant toutes les fins de lignes dans le repo pour qu'elles correspondent à l'option .gitattributes et de valider ces changements -- voir J'essaie de corriger les fins de lignes avec git filter-branch, mais je n'ai pas de chance. .

Si vous voulez vraiment essayer de revenir sur les modifications apportées au fichier manuellement, la solution la plus simple semble être d'effacer les fichiers modifiés, puis de demander à git de les restaurer, bien que je note que cette solution ne semble pas fonctionner de manière cohérente 100% du temps ( AVERTISSEMENT : NE PAS exécutez ceci si vos fichiers modifiés ont des changements autres que des fins de ligne ! !!):

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

Notez que, à moins que vous ne normalisiez les fins de ligne dans le référentiel à un moment donné, vous continuerez à rencontrer 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, disons qu'un chemin comme le suivant existe dans le référentiel :

/foo/bar

Maintenant, quelqu'un sur Linux commet des fichiers dans /foo/Bar (probablement à cause d'un outil de construction ou autre 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

L'utilisation de ce dépôt sous Windows ou Mac peut entraîner des modifications de l'environnement de travail. fileA qui ne peuvent pas être réinitialisés, parce qu'à chaque réinitialisation, git sur Windows vérifie /foo/bar/fileA et, parce que Windows ne tient pas compte des majuscules et des minuscules, il écrase le contenu de l'adresse suivante fileA con /foo/Bar/fileA ce qui fait qu'ils sont "modifiés".

Un autre cas peut être un ou plusieurs fichiers individuels qui existent dans le dépôt et qui, lorsqu'ils sont extraits sur un système de fichiers insensible à la casse, se chevauchent. Par exemple :

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

D'autres situations similaires peuvent être à l'origine 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 cette discussion et les correctifs proposés connexes sur la liste de diffusion git.git).

Solution

La solution consiste à faire coïncider le cas des fichiers dans l'index git et le cas du système de fichiers Windows. Cela peut être fait soit sous Linux, ce qui montrera l'état réel des choses, soit sous Windows avec un utilitaire open source très utile. Git-Unite . Git-Unite appliquera les changements de cas nécessaires à l'index git, qui pourra ensuite être commité dans le repo.

(1) Il s'agit probablement de quelqu'un qui utilise Windows, sans aucune connaissance de l'anglais. .gitattributes pour le fichier en question, et en utilisant le paramètre global par défaut pour le fichier core.autocrlf qui est false (voir (2)).

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

Answer 2

Si les autres réponses ne fonctionnent pas, essayez d'ajouter les fichiers, puis de réinitialiser

$ git add -A
$ git reset --hard

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

Answer 3

Une autre cause de ce phénomène pourrait être systèmes de fichiers insensibles à la casse . Si vous avez plusieurs dossiers dans votre dépôt au même niveau dont les noms ne diffèrent que par la casse, vous serez touché par ce problème. Parcourez le dépôt de sources en utilisant son interface web (par exemple GitHub ou VSTS) pour vous en assurer.

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

Answer 4

Puedes stash loin de vos changements, puis laissez tomber la cachette :

git stash
git stash drop

Answer 5

Exécuter nettoyer commandement :

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

git clean -fd