Impossible de supprimer les modifications dans Git
Après avoir vu ce qui suit à partir de la ligne de commande:
# On branch RB_3.0.10
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: index.htm
J'essaie de supprimer mes modifications en tapant la commande:
git checkout -- index.htm
mais quand je relance le statut git, il a exactement le même aspect La caisse ne semble pas fonctionner. Est-ce que je fais quelque chose de mal? J'utilise GIT 1.6.1.2 sur Windows/Cygwin.
# On branch RB_3.0.10
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: index.htm
Voici mon expérience, définissez les variables suivantes dans .git/config:
[core]
autocrlf = false
safecrlf = false
eol = crlf
puis lancez $ git checkout HEAD ., et ça marche. mais $ git checkout -- . pas, étrange!
* version git 1.9.3
Quels changements git diff affiche-t-il sur le fichier? Sur Windows, j'ai vu des problèmes avec les fins de ligne qui causaient des problèmes comme celui-ci. Dans ce cas, examinez les paramètres que vous avez définis pour git config core.autocrlf et git config core.safecrlf. Il existe une documentation pour ces paramètres ici .
Je dirais que si vous utilisez git svn pour l'intégration avec Subversion, assurez-vous que autocrlf est désactivé. D'après ce que je peux dire, cette configuration est simplement interrompue et la plupart des outils pensent que les fichiers ont été modifiés, lorsque vous avez effectué une checkout pour annuler les modifications.
Si vous rencontrez un problème à cause de git checkout et que git status indique que le fichier est toujours modifié et que git diff indique que le fichier est modifié sur chaque ligne du fichier, il s'agit du problème que vous rencontrez.
core.autocrlf
Si la valeur est true, git convertit CRLF à la fin des lignes des fichiers texte en LF lors de la lecture du système de fichiers, et convertir en sens inverse lors de l'écriture dans le système de fichiers. La variable peut être définie sur entrée, auquel cas la conversion ne se produit que lors de la lecture du fichier système de fichiers mais les fichiers sont écrits avec LF à la fin des lignes . Actuellement, quels chemins à considérer "texte" (c'est-à-dire être soumis au mécanisme autocrlf) est décidé purement basé sur le contenu.
core.safecrlf
Si la valeur est true, git vérifie si la conversion de CRLF est contrôlée par core.autocrlf est réversible. Git sera vérifier si une commande modifie un fichier dans l'arbre de travail soit directement ou indirectement. Par exemple, commettre un fichier suivi en vérifiant le même Le fichier doit donner le fichier original en l'arbre de travail. Si ce n'est pas le cas pour le réglage actuel de core.autocrlf, git rejettera le fichier. La variable peut être définie sur "avertir", dans ce cas, git ne fera que avertir d'une conversion irréversible mais continue l'opération . ...
Cela me dérange depuis un moment, presque toutes les pensions que je vérifiais avaient des modifications que je ne pouvais pas ignorer. Longue histoire courte, j'ai essayé tout ce qui précède, rien n'a fonctionné. Voici ce que j'ai fait pour que les choses redeviennent normales (sur un Mac):
Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo's local config ./.git/config
git rm --cached -r .
git reset --hard
Je pense que vous devez passer -f
Depuis la page de manuel (man git-checkout, GIT-CHECKOUT (1)):
-f, --force
Continuez même si l'index ou l'arbre de travail diffère de HEAD.
Ceci est utilisé pour jeter les changements locaux .
Par exemple, ignorez les modifications sur la branche actuelle et passez à une autre branche:
git checkout -f master
Ce peut être une fin de ligne, comme le suggère @ 1800-information, mais une autre possibilité est que la différence (cela vous empêche de restaurer ces fichiers avec une commande d'extraction) est celle du mode fichier. Voilà ce qui m'est arrivé. Sur ma version de git, vous pouvez découvrir cela en utilisant
git diff index.htm
Et il vous montrera les changements de mode de fichier. Il ne vous laissera toujours pas les rétablir, cependant, en utilisant checkout, même avec l'option -f. Pour cette utilisation soit
git config core.filemode false
ou changez votre git .config dans votre éditeur de texte en ajoutant
[coeur]
filemode = false
Après cela, vous pouvez utiliser
git reset HEAD index.htm
et le fichier devrait disparaître.
(J'ai tout cela dans les réponses à Comment puis-je modifier le mode git ignore (chmod)? et update-file-permissions-only-in-git )
Êtes-vous sur OSX ou Windows? Si c'est le cas, le problème est probablement d'avoir deux fichiers du même nom, avec une casse différente. par exemple. index.htm et index.htm
Windows, et par défaut OSX, utilise un système de fichiers insensible à la casse, qui entre en conflit avec le git sensible à la casse.
J'ai eu ce problème et après avoir essayé tout ce qui précède, rien n'a fonctionné.
Ce qui a bien fonctionné pour moi, c’est de supprimer le répertoire dans lequel se trouve le fichier, puis git status et de s’assurer que tous les fichiers de ce répertoire sont maintenant marqués comme supprimés. Après cela, j'ai simplement fait git checkout -f et tout était rentré dans l'ordre.
Je travaillais sur un projet libGDX sur Android Studio et je voulais annuler tous les changements que j'avais apportés et rien ne fonctionnait pour moi; la solution que j'ai proposée consistait à appliquer tous les changements à une nouvelle branche
git checkout -b TRASH
git add .
git commit -m "discarded changes"
git checkout master
et ensuite vous pouvez supprimer la branche TRASH si vous le souhaitez.
J'avais un problème d'autorisations dans Windows et je devais faire icacls containingFolder /reset /t /l /c, puis double-cliquer sur le dossier pour récupérer mes autorisations.
C'est une vieille question, mais qui me concernait toujours. Je n'ai pas trouvé ma réponse avant de demander autour du bureau et j'ai découvert que le problème était lié aux sous-modules. Lorsqu'elles sont mises à jour et que votre propre référentiel ne reflète pas ces modifications, il apparaît que des différences existent, il n'est pas utile de redimensionner la tête. Si c'est le cas, lancez:
git status update
Cela devrait aider à arranger les choses (dans ce cas particulier)
J'ai eu un problème similaire, qui ne me permettait pas de supprimer des fichiers qui n'existent pas ou qui ont été modifiés. J'utilise Visual Studio au travail et j'ai constaté que cela se produit lors du changement de branche lorsque l'application est en cours d'exécution.
git checkout et essayer de jeter n'a pas aidé. Cela ne fonctionnerait pas ou cela me dirait simplement que je n'ai pas la permission.
Solution qui a fonctionné:
- Allez dans Mode sans échec
- Supprimer les fichiers
Redémarrer est une douleur, mais cela a fonctionné plus rapidement que d'essayer 100 choses.
Il y a une solution facile. Si cela se produit (normalement suite à un arrêt inattendu de Windows ou à un vidage de la mémoire) et que vous ne pouvez pas ignorer vos modifications et même basculer d'une branche à l'autre (Git dit que vous ne disposez pas de la permission nécessaire) dans Windows environment show all hidden files and folders à partir des options de dossier. Allez dans votre répertoire GIT (commencez par .git) et supprimez le fichier "index.lock". Ensuite, Git devrait vous laisser faire ce que vous voulez.
J'ai également rencontré un problème quelque peu similaire et les étapes suivantes m'ont aidé:
git commit -am 'temp commit'
git pull Origin master
git reset head~1
git reset head --hard
J'espère que cela aide aussi les autres.
Dans mon cas, je ne pouvais pas ignorer les modifications liées à un répertoire. par exemple. quand je courais un diff git je verrais ceci:
-Subproject commit fdcccccccccccccccccccccccccccccccccccccc
+Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
Alors j'ai appelé ce répertoire et j'ai lancé un statut de git. C'était à l'état HEAD détaché. Et puis je viens de lancer un git checkout master dedans. Cela a réglé les choses pour moi. Mais ce n'est pas utile pour le scénario exact demandé ici.
J'ai fini par faire un git stash suivi d'un git stash clean pour m'en débarrasser. Je n'ai vu aucune configuration auto cr/lf dans les fichiers .git/ou ~/.git.