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

J'ai également essayé git reset ., git checkout -- .et git checkout-index -f -aen vain.

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

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 qu'en .gitattributes j'ai:

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

En outre, autocrlfest défini sur false dans mon global .gitconfig. Cela pourrait-il être pertinent d'une manière ou d'une autre?

J'ai eu le même problème et il était lié au .gitattributesfichier. Toutefois, le type de fichier à l'origine du problème n'a pas été 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

RÉSOLU!!!

J'ai résolu ce problème en suivant les étapes suivantes

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/

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 toutes les modifications, ce qui amènera Git à être au courant de ces fichiers, puis à les réinitialiser.

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

$ git stash
$ git stash drop

Si vous utilisez Git pour Windows, c'est probablement votre problème

J'ai eu le même problème et la sauvegarde, la réinitialisation matérielle, le nettoyage ou même tous laissaient des changements. 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. Il s'agit d'un "problème connu" avec git pour Windows. Les modifications locales s'affichent dans gitk et git comme l'ancien mode 100755, le nouveau mode 100644, sans aucune différence de fichier réelle.

Le correctif consiste à ignorer le mode fichier:

git config core.filemode false

Plus d'infos ici

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

Il semble que le .gitattributesdossier, contenant:

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

fait apparaître les fichiers de projet sans mise en scène. Je ne sais pas pourquoi, et j'espère vraiment que quelqu'un connaissant les manières de git nous donnera une belle explication.

Ma solution consistait à supprimer ces fichiers et à les ajouter autocrlf = falsesous [core]dans.git/config .

Cela ne revient pas exactement à la même chose que la configuration précédente, car cela nécessite que chaque développeur ait autocrlf = false . J'aimerais trouver une meilleure solution.

ÉDITER:

J'ai commenté les lignes incriminantes, je ne les ai pas commentées 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 soit des fins de ligne incorrectes, soit des fins de ligne mixtes. Pour confirmer, vérifiez que git diffne montre que les changements dans les fins de ligne (ceux-ci peuvent ne pas être visibles par défaut, essayez git diff | cat -vde voir les retours chariot comme littéraux^M caractères ).

Par la suite, quelqu'un a probablement ajouté .gitattributesou modifié lecore.autocrlf paramètre pour normaliser les fins de ligne (2). Sur la base de la .gitattributesconfiguration globale ou, Git a appliqué des modifications locales à votre copie de travail qui appliquent la normalisation de fin de ligne demandée. Malheureusement, pour une raison quelconquegit reset --hard ces modifications de normalisation de ligne ne sont pas annulées.

Solution

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

La meilleure option est de laisser git appliquer la normalisation qu'il souhaite en normalisant toutes les fins de ligne dans le repo pour correspondre à .gitattributes, et en validant ces changements - voir Essayer de réparer les fins de ligne avec git filter-branch, mais sans chance .

Si vous voulez vraiment essayer d'annuler les modifications du fichier manuellement, la solution la plus simple semble être d'effacer les fichiers modifiés, puis de dire à git de les restaurer, bien que je note que cette solution ne semble pas fonctionner de manière cohérente à 100%. l'heure ( AVERTISSEMENT: NE l' exécutez PAS 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, supposons qu'un chemin comme celui-ci existe dans le référentiel:

/foo/bar

Maintenant, quelqu'un sur Linux valide les fichiers /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 maintenant de deux répertoires distincts:

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

La vérification de ce dépôt sur Windows ou Mac peut entraîner une modification fileAqui ne peut pas être réinitialisée, car à chaque réinitialisation, git sur Windows extrait /foo/bar/fileA, puis parce que Windows ne respecte pas la casse, écrase le contenu de fileAavec /foo/Bar/fileA, ce qui entraîne leur "modification".

Un autre cas peut être un ou des fichiers individuels qui existent dans le référentiel 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

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 à l'avenir - voir cette discussion et les correctifs proposés sur la liste de diffusion git.git).

Solution

La solution consiste à aligner la casse des fichiers dans l'index git et la casse sur le système de fichiers Windows. Cela peut être fait sous Linux qui montrera le vrai état des choses, OU sous Windows avec l'utilitaire open source très utile Git-Unite . Git-Unite appliquera les modifications de cas nécessaires à l'index git, qui pourra ensuite être validé dans le dépôt.

(1) Cela était probablement dû à une personne utilisant Windows, sans aucune .gitattributesdéfinition du fichier en question, et utilisant le paramètre global par défaut core.autocrlfqui est false(voir (2)).

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

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.

Une autre cause à cela pourrait être les 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 frappé 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

Vous pouvez stashsupprimer vos modifications, puis laisser tomber la cachette:

git stash
git stash drop

Aucune de ces méthodes n'a fonctionné pour moi, la seule solution était de neutraliser l'ensemble du référentiel et de le recloner. Cela inclut le stockage, la réinitialisation, l'ajout puis la réinitialisation, les paramètres clrf, la sensibilité à la casse, etc. Soupir.

Exécuter la commande de nettoyage :

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

git clean -fd

Vérifiez votre .gitattributes.

Dans mon cas, je l'ai *.js text eol=lfet 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 git reset --hard HEADn'a même rien fait.

Je le corrige en commentant *.js text eol=lfdans mon .gitattributeset je le commente après.

On dirait que c'est juste de la magie.

J'ai rencontré un problème similaire impliquant également .gitattributes, mais pour mon cas, il s'agissait du LFS de GitHub. Bien que ce ne soit pas exactement le scénario de l'OP, je pense qu'il fournit une occasion d'illustrer ce que fait le .gitattributesfichier et pourquoi il peut conduire à des changements non organisé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. Dans un commit récent, j'ai ajouté une nouvelle git-lfs trackrègle en utilisant un modèle qui était rétrospectivement un peu trop large, et finissant 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 maintenant il était dans mes modifications non programmées et aucune quantité de retraits ou de réinitialisations matérielles sur ce fichier n'allait le réparer. Pourquoi?

L'extension GitHub LFS fonctionne principalement en tirant parti des crochets qui gitpermettent d'accéder via le .gitattributesfichier. Généralement, les entrées dans .gitattributesspé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 qui gits'affiche lors du calcul d'un git diffne 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 .gitattributesmodèle qui lui correspond, il apparaîtra comme des modifications non programmées dans le rapport d'état, même s'il n'y a vraiment pas de modification dans le fichier.

Cela dit, ma «réponse» à la question est que si le changement de .gitattributesfichier est quelque chose que vous vouliez faire, vous devriez vraiment simplement ajouter les changements et continuer. Sinon, modifiez le .gitattributespour mieux représenter ce que vous voulez faire.

Références

1. Spécification GitHub LFS - Grande description de la façon dont ils se connectent aux appels de fonction cleanet smudgepour remplacer votre fichier dans les gitobjets 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 gittraite vos documents.

J'ai eu le même problème. Je l'ai fait, git reset --hard HEADmais chaque fois que je l'ai fait, git statusje 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 un terminal sur mon Mac OS) et je l'ai réessayé et cela a fonctionné.

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

Je crois qu'il y a un problème avec git pour Windows où git écrit au hasard les mauvaises fins de ligne lors du paiement et la seule solution consiste à extraire une autre branche et à forcer git à ignorer les modifications. Vérifiez ensuite la branche sur laquelle vous souhaitez réellement travailler.

git checkout master -f
git checkout <your branch>

Sachez que cela annulera toutes les modifications que vous pourriez avoir intentionnellement apportées, donc ne faites cela que si vous rencontrez ce problème immédiatement après le paiement.

Edit: j'aurais peut-être eu de la chance la première fois. Il s'avère que je me suis de nouveau mordu après avoir changé de branche. Il s'est avéré que les fichiers git rapportaient comme modifiés après le changement de branche. (Apparemment, car git n'appliquait pas correctement la fin de la ligne CRLF aux fichiers.)

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

Problème similaire, bien que je ne sois sûr qu'en surface. Quoi qu'il en soit, cela peut aider quelqu'un: ce que j'ai fait (FWIW, dans SourceTree): a caché le fichier non engagé, puis a 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é le fichier svg pour les icônes dans mon projet.

Pour résoudre ce problème, je préviens git que les fichiers svg doivent être traités comme binaires au lieu de texte en ajoutant la ligne ci-dessous à .gitattributes

* .svg binaire

Dans une situation similaire. À la suite de nombreuses années de tourments avec de nombreux programmeurs qui ont pu bourrer différents encodages des fins de lignes (. Asp , .js, .css ... pas l'essentiel) dans un seul fichier. Il y a quelque temps a refusé .gitattributes. Paramètres de repo gauche autorclf = trueet safecrlf = 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 avoir copié à partir 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

Une autre possibilité que j'ai rencontrée était que l'un des packages du référentiel se soit retrouvé avec une HEAD détachée. Si aucune des réponses ici n'aide et que vous rencontrez un message d'état git comme celui-ci, vous pourriez avoir 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)

Entrer dans le path/to/packagedossier a git statusdevrait donner le résultat suivant:

HEAD detached at 7515f05

Et la commande suivante devrait alors résoudre le problème, où masterdevrait être remplacé par votre branche locale:

git checkout master

Et vous obtiendrez un message indiquant que votre branche locale aura un certain nombre de validations derrière la branche distante. git pullet vous devriez être hors des bois!

Pour certaines raisons

git add .

n'a pas fonctionné , mais

$ git add -A

élaboré!