git rebase: "erreur: impossible de stat 'fichier': autorisation refusée"

J'utilise git et j'ai fait un petit commit suivi d'un gros. J'ai décidé d'utiliser git rebasepour écraser les deux commits ensemble avant de les pousser. (Je n'ai jamais fait cela auparavant.)

J'ai donc fait:

git rebase -i HEAD~2

Cela m'a donné mon éditeur, où j'ai choisi de choisir le commit précédent et d'écraser le dernier. Quand j'ai sauvé, git a dit:

erreur: impossible de stat ' nom de fichier ': autorisation refusée

Impossible d'appliquer sha1 pour une validation ultérieure ... ligne de texte initiale pour cette validation

Maintenant:

• Aucun commit n'apparaît quand je le fais git log.
• git status me dit que je ne suis "actuellement sur aucune branche".
• Un fichier est répertorié comme modifié et dans l'index, et deux fichiers sont répertoriés comme non suivis. Mon premier commit n'avait qu'un seul fichier (je pense), et mon second commit en avait une bonne douzaine.

Qu'est-il arrivé!? Comment je le répare?

Je n'ai vu cette erreur que sur Windows et cela semble vouloir dire que quelque chose a empêché git de modifier un fichier au moment où il a essayé d'appliquer un patch.

Windows tend à donner aux processus un accès exclusif aux fichiers quand cela ne devrait pas être vraiment nécessaire, dans le passé, les antivirus ont été une source de suspicion, mais je n'ai jamais prouvé cela de manière concluante.

La chose la plus simple à faire est probablement d'interrompre et de réessayer, en espérant que cela ne se produira pas la prochaine fois.

git rebase --abort

Vous pouvez essayer d'utiliser git applyet de savoir ce que commit git essayait réellement de faire avant de le faire, git rebase --continuemais en toute honnêteté, je ne recommanderais pas cela. La plupart du temps, j'ai vu cela essayé, il y a eu une chance meilleure que nulle que quelque chose soit accidentellement manqué ou foiré.

Essayez de fermer tous les programmes dont le dossier est ouvert, tels que les éditeurs, les fenêtres de l'explorateur, les invites de commande et les programmes FTP. Cela résout toujours le problème pour moi sous Windows.

Fermez simplement votre IDE (VISUAL STUDIO / ATOM, etc.). Cela peut fonctionner

Quand je vois cela sur ma machine, c'est pire qu'un simple "certains processus ont le fichier ouvert". La propriété réelle du fichier est détournée au point où je (en tant qu'administrateur) ne peux y accéder qu'après le redémarrage.

Le plus proche que je peux dire, IIS fait partie du problème. Si je bascule entre deux branches principales qui nécessitent beaucoup de fichiers à modifier, git supprimera un fichier ou un répertoire (généralement des DLL) pendant qu'IIS essaie de faire quelque chose avec lui. À ce stade, le processus IIS écrase automatiquement le fichier sur le disque avec une version verrouillée et ne semble appartenir à personne.

Arrêter IIS à ce stade ne le fait pas. Le mieux que j'ai découvert est de redémarrer et n'oubliez pas d'arrêter IIS avant de changer dans les principales branches à l'avenir.

Je sais que cela ne répond pas vraiment à la question, mais pourrait être utile aux autres.

Sous Windows, il peut s'agir d'un processus TortoiseGIT qui bloque ces fichiers. Ouvrez le gestionnaire de tâches et terminez le processus TGitCache.exe .

Je suis juste tombé sur ce fil de réponses - cette erreur est une erreur fausse. # Erreur: impossible de stat 'reddit / app / views / links': autorisation refusée

C'est tout ce que j'ai - en essayant de fusionner. J'ai lu quelques-unes des réponses, puis j'ai réalisé - tout ce que j'avais à faire était de fermer mon éditeur de code qui se trouve être Atom.

Une fois l'éditeur fermé - j'ai relancé "git merge" et boom, ça a marché.

Quelle erreur inutile :(

si vous utilisez vscode, supprimez le terminal et ouvrez-en un nouveau. sinon peut-être aussi fermer le terminal

Cela m'arrive parfois dans Windows

erreur: impossible de stat 'nom de fichier': autorisation refusée

Le plus souvent, j'ai plusieurs instances de bit bash ouvertes, et l'une des instances de git bash se trouve dans un répertoire qui n'existe pas dans la branche distante dont je tire.

La fermeture de toutes les instances de git bash sauf une résout le problème pour moi.

Si l'IDE que vous utilisez (au cas où vous en utilisez un) pourrait également gêner. C'est ce qui m'est arrivé lors de l'utilisation de QtCreator.

L'utilisation de SourceTree dans Win 10 a résolu le problème en fermant l'éditeur Atom.

Erreur de reproduction:

1. Dans la branche B, créez un fichier md, en utilisant Atom, éditez-le, enregistrez et validez.
2. Basculez vers la branche A, déroulez de nouvelles validations depuis le serveur.
3. Essayez de revenir en arrière, Opps, il est dit "erreur: impossible de stat 'fichier': autorisation refusée".

Cela peut également se produire lorsque vous utilisez SublimeText et que la fenêtre contextuelle vous demandant d'acheter le programme n'est pas fermée.

Cela se produit souvent lorsque des logiciels / applications de prétraitement surveillent le projet, tels que Prepros ou Codekit. En outre, Atom et Sublime (et même Notepad ++) peuvent provoquer ce problème si un fichier du projet est en cours de modification.

Le moyen le plus simple de contourner le problème est de fermer tout ce qui a ouvert les fichiers du projet, de fusionner vos branches, puis de les rouvrir pour le rafraîchir. Cela évitera également tout problème où le programme n'est plus au courant des changements qui se sont produits, vous obligeant à actualiser le (s) projet (s) à la main.

Si vous utilisez Webpack, arrêtez-le. Arrêtez également votre IDE. Devrait bien fonctionner après avoir fait ces choses.

J'avais un problème similaire. Mais c'était très simple à résoudre. Sur une machine Windows, mon explorateur de fichiers avait un dossier ouvert qui existait dans une branche mais pas dans l'autre que j'ai extrait. La fermeture de l'explorateur de fichiers a résolu le problème.

Je viens de l'avoir sous Win 7.

$ git stash pop error: impossible de stat 'parentFolder / subfolder': Autorisation refusée erreur: impossible stat 'parentFolder / subfolder': Autorisation refusée

Diagnostic:

1> Je suis allé dans le sous-dossier et il est là et je n'ai pas pu le supprimer!

2> Utilisez "Explorateur de processus" -> Rechercher -> Rechercher des poignées et des DLL -> mettez le nom du "sous-dossier" là-bas et recherchez.

Résultat: il s'avère que XMLSpy a ouvert l'un des fichiers XML, fermez XML Spy et essayez à nouveau de masquer la pop, cela fonctionne maintenant.

Cela m'est arrivé sous Windows lors du rebasage à l'intérieur du terminal intégré IntelliJ . J'ai remarqué que j'avais une instance de client Git bash fonctionnant en parallèle.

La fermeture de Git bash a résolu le problème.

Ma rencontre avec ce problème a été causée par mon éditeur, Intellij. Dans le cadre de ses contrôles de version internes, il avait parcouru et verrouillé tous les fichiers git cachés. (Pour diverses raisons, je n'utilisais pas le plugin git fourni avec Intellij ...)

J'ai donc ouvert une fenêtre DOS normale en tant qu'administrateur, changé pour le répertoire et exécuté

attrib -R /S

Cela a supprimé le verrou sur les fichiers et tout a fonctionné après cela et j'ai pu synchroniser mes modifications à l'aide du client Windows GitHub.

Je suis d'accord avec les réponses ci-dessus "Fermer Visual Studio".

Cependant, une étape supplémentaire que je devais faire même après avoir fermé Visual Studio était de tuer manuellement le processus Visual Studio "devenv.exe" dans l'Explorateur de tâches. Après avoir fait cela, j'ai pu à nouveau exécuter dans gitbash:

git pull

et l' erreur " Can't Stat Filename " a disparu. Cela est peut-être dû à une extension de Visual Studio qui maintient le processus ouvert plus longtemps même après la fermeture.

Je viens d'avoir ce problème. Le truc, c'est que si vous aviez ouvert un fichier qui a été supprimé \ remplacé après rebase (vous aviez une branche qui n'a plus ce fichier), le système git corrompt. J'ai donc fermé tous les fichiers ouverts, puis j'ai essayé de passer à la caisse sur une autre branche

Une solution alternative plutôt que de fermer toutes les applications qui pourraient verrouiller le répertoire comme à peu près toutes les autres réponses disent, serait d'utiliser un utilitaire qui déverrouillera les fichiers / répertoire sans tout fermer. (Je déteste avoir besoin de redémarrer Visual Studio)

LockHunter est celui que j'utilise: https://lockhunter.com/ Il y en a probablement d'autres aussi, mais celui-ci a très bien fonctionné pour moi.

Même problème sur Windows 10 64 bits, exécutant Git Bash version 2.9.0.windows1 en utilisant Atom comme mon éditeur.

Cela a fonctionné pour moi: j'ai ajouté le dossier du logiciel Git (pour moi, c'était C: \ Program Files \ Git) aux exclusions pour Windows Defender.

Après l'ajout de l'exclusion, git checkout 'file'a bien fonctionné.

Cette erreur peut également être due au fait que les fichiers sont toujours "verrouillés" en raison d'actions git antérieures. Cela a à voir avec le fonctionnement de la couche système de fichiers Windows. J'ai lu une fois une belle explication à ce sujet, mais je ne me souviens pas où.

Dans ce cas cependant, comme il s'agit essentiellement d'une condition de concurrence , tout ce que vous avez à faire est de poursuivre votre processus de rebase interrompu . Malheureusement, cela m'arrive tout le temps, alors j'ai écrit ce petit assistant dangereux pour continuer mes rebases:

#!/bin/sh

set -e

git checkout .
git clean -df
git rebase --continue

Si vous voulez être plus sûr, vous pouvez utiliser git rebase --edit-todopour vérifier si le prochain commit à appliquer est vraiment celui qui n'a pas été appliqué auparavant. Utilisez git clean -dnpour vous assurer de ne supprimer aucun fichier important.

Cela m'est arrivé dans Windows, lors de l'utilisation de photoshop: lorsque j'ai enregistré une image, puis que je suis passé à une branche (laissant photoshop avec l'image ouverte), j'ai eu l'erreur git. Fermez l'image dans Photoshop et réessayez

Si vous avez ouvert l' outil de fusion de fusion , fermez-le. Il bloque l'écrasement du fichier.

Tuer le processus w3wp.exe lié au référentiel a corrigé cela pour moi.

Dans mon cas, j'avais un serveur de développement webpack derrière.

J'ai eu cette erreur lorsque mon VS1013 était sur une branche ciblant 8.1 et j'essayais de commander une branche 8.0. J'avais besoin de revenir sur VS et de l'autoriser à UpdateAll. Ensuite, j'ai pu vérifier la branche 8.0 sans erreur.

J'étais également sur une machine Windows utilisant Git Shell lorsque j'ai rencontré la même erreur.

Cependant, à l'époque, j'avais plusieurs terminaux Git ouverts.

Le premier terminal a reçu l'erreur que vous avez signalée ci-dessus et l'autre terminal avait précédemment exécuté la grunt servecommande de terminal de yeoman (lié ci-dessous). Le deuxième terminal devait rester ouvert pour héberger une instance de serveur local.

L'arrêt de toutes les fenêtres de terminal exécutant des processus en cours peut entraîner la disparition de l'erreur.

C'est du moins ce qui a fonctionné pour moi. Après avoir fermé la deuxième fenêtre du terminal, je pouvais facilement extraire différentes branches et manipuler des fichiers.

Commande Grunt Serve - Yeoman.I / O
http://yeoman.io/learning/

Je viens de rencontrer ce problème. Aucune des réponses ici n'est parvenue à résoudre ce problème pour moi.

J'ai fini par être des paquets de pépites que j'ai ajoutés sur une branche qui, une fois revenue à la branche principale, semblait ne pas exister. Une fois que j'ai fait une fusion, cela dirait que newtonsoft ... xml ne pouvait pas stat. Je voudrais aller au fichier en question et l'ouvrir mais Windows a renvoyé une erreur en disant qu'il ne peut pas trouver le fichier (même si je le regardais bien)

Comment j'ai résolu cela était un clic droit supprimer le fichier (qui a fonctionné mais je ne pouvais pas l'ouvrir parce que Windows ne pouvait pas le trouver ???) et essayer de fusionner à nouveau et cela a résolu le problème.

Très étrange.

J'espère que cela aidera quelqu'un plus tard.

Je suis sorti de mon éditeur de texte qui accédait aux répertoires du projet, puis j'ai essayé de fusionner avec la branche principale et cela a fonctionné.