web-dev-qa-db-fra.com

Comment puis-je supprimer les fichiers disant "ancien mode 100755 nouveau mode 100644" des modifications non mises en scène dans Git?

Pour une raison quelconque, lorsque j'ai initialement extrait du référentiel d'un de mes projets git, j'ai eu une tonne de fichiers dans ma copie de travail qui ne comportaient aucune modification visible, mais qui continuaient à apparaître dans mon unstaged changes région.

J'utilise Git Gui sur Windows XP, et quand je vais regarder le fichier pour voir ce qui a changé. Tout ce que je vois c'est:

old mode 100755  
new mode 100644

Est-ce que quelqu'un sait ce que cela signifie?

Comment puis-je extraire ces fichiers de ma liste de modifications non mises en scène? (Très ennuyeux d'avoir à parcourir des centaines de fichiers, juste pour choisir les fichiers que j'ai récemment édités et que je veux valider).

gitgit-gui
649
concept47

Cela ressemble pour moi à des modes de permissions de fichiers unix (755 = rwxr-xr-x, 644 = rw-r--r--) - l'ancien mode incluait l'indicateur + x (exécutable), le nouveau mode ne pas.

Les réponses de ce problème msysgit suggère de définir core.filemode sur false pour se débarrasser du problème:

git config core.filemode false
1146
Amber

Régler core.filemode sur false fonctionne, mais assurez-vous que les paramètres de ~/.gitconfig ne sont pas remplacés par ceux de .git/config.

87
NovelX

J'ai rencontré ce problème lors de la copie à plusieurs reprises d'un dépôt Git contenant des fichiers de travail d'un ancien disque dur. Le problème provient du fait que le propriétaire et les autorisations sont passés de l'ancien lecteur/ordinateur au nouveau. En résumé, exécutez les commandes suivantes pour redresser la situation ( grâce à cette réponse du superutilisateur ):

Sudo chmod -R -x . # remove the executable bit from all files

L'ancienne commande résoudra réellement les différences signalées par git diff, mais vous révoquera votre capacité à répertorier les répertoires. ls ./ échoue avec ls: .: Permission denied. Pour résoudre ce problème:

Sudo chmod -R +X . # add the executable bit only for directories

La mauvaise nouvelle est que, si vous souhaitez conserver certains fichiers, tels que les scripts .sh, vous devez les rétablir. Vous pouvez le faire avec la commande suivante pour chaque fichier:

chmod +x ./build.sh # where build.sh is the file you want to make executable again
18
Scott Willeke

Il semble que vous ayez modifié certaines autorisations du répertoire. J'ai fait les étapes suivantes pour le restaurer.

$  git diff > backup-diff.txt                ### in case you have some other code changes 

$  git checkout .
4
SuperNova

Vous pouvez essayer git reset --hard HEAD pour réinitialiser le référentiel à l'état par défaut attendu.

3
Doppelganger

J'ai fait face au même problème. Et cela sauve ma vie: https://Gist.github.com/jtdp/5443498

git diff -p -R --no-color \ | grep -E "^(diff|(old|new) mode)" --color=never \ | git apply

1
zsoh

Cela se produit généralement lorsque le référentiel est cloné entre des machines Windows et des machines Linux/Unix.

Il suffit de dire à git d’ignorer le changement de filemode, voici plusieurs manières:

  1. Config UNIQUEMENT pour le dépôt actuel:

    git config core.filemode false

  2. Config globalement:

    git config --global core.filemode false

  3. Ajouter dans ~/.gitconfig:

    [core]
     filemode = false

Il suffit de sélectionner l'un d'entre eux.

1
K. Symbol

Cela se produit lorsque vous extrayez et que tous les fichiers étaient exécutables dans le référentiel distant. En les rendant exécutables à nouveau, tout reviendra à la normale.

chmod +x <yourfile> //For one file
chmod +x folder/* // For files in a folder

Vous devrez peut-être faire:

chmod -x <file> // Removes execute bit

au lieu de cela, pour les fichiers qui n'étaient pas définis comme exécutables et qui ont été modifiés à cause de l'opération ci-dessus. Il existe un meilleur moyen de le faire, mais il ne s'agit que d'une solution très rapide et sale.

1
IskandarG

Vous pouvez utiliser la commande suivante pour changer votre mode de fichier. git add --chmod=+x -- filename Puis validez dans la branche.

0
Wae

Je viens de rencontrer ce problème lorsque je diffère de ma branche avec maître. Git a renvoyé une erreur de "mode" quand je m'attendais à ce que ma branche soit identique à maître. J'ai corrigé en supprimant le fichier puis en fusionnant le maître à nouveau.

D'abord j'ai couru le diff:

git checkout my-branch
git diff master

Cela a renvoyé:

diff --git a/bin/script.sh b/bin/script.sh
old mode 100755
new mode 100644

J'ai alors couru ce qui suit pour réparer:

rm bin/script.sh
git merge -X theirs master

Après cela, git diff n'a renvoyé aucune différence entre my-branch et master.

0
Collin Krawll

Je n'avais qu'un fichier gênant avec les autorisations modifiées. Pour le restaurer individuellement, je l'ai simplement supprimé manuellement avec rm <file>, puis j'ai effectué une vérification pour en extraire une nouvelle copie.

Heureusement, je ne l'avais pas encore mis en scène.

Si j'avais eu j'aurais pu exécuter git reset -- <file> avant d'exécuter git checkout -- <file>

0
kEnobus