Comment puis-je faire Git d'ignorer mode fichier (chmod) des changements?

J'ai un projet dans lequel je dois changer le mode de fichiers avec chmod 777 pendant le développement, mais qui ne devrait pas changer dans les principaux repo.

Git ramasse sur chmod -R 777 . et les marques de tous les fichiers modifiés. Est-il un moyen de faire Git d'ignorer les changements de mode qui ont été apportées aux fichiers?

Ceci est utile lorsque vous travaillez avec git sur Windows + Bash sur Ubuntu que sur Windows
Pour ceux qui veulent juste pour ignorer les modifications des autorisations pour une invocation de git diff, et qui, par conséquent, ne pas vouloir changer leurs Git fichiers de configuration: vous pouvez utiliser git diff -G. par Zed réponse de ici.

InformationsquelleAutor Marcus Westin | 2009-10-16

3502

Essayer:
```
git config core.fileMode false
```
De git-config(1):
```
core.fileMode
    Tells Git if the executable bit of files in the working tree
    is to be honored.

    Some filesystems lose the executable bit when a file that is
    marked as executable is checked out, or checks out a
    non-executable file with executable bit on. git-clone(1)
    or git-init(1) probe the filesystem to see if it handles the 
    executable bit correctly and this variable is automatically
    set as necessary.

    A repository, however, may be on a filesystem that handles
    the filemode correctly, and this variable is set to true when
    created, but later may be made accessible from another
    environment that loses the filemode (e.g. exporting ext4
    via CIFS mount, visiting a Cygwin created repository with Git
    for Windows or Eclipse). In such a case it may be necessary
    to set this variable to false. See git-update-index(1).

    The default is true (when core.filemode is not specified
    in the config file).
```
La -c indicateur peut être utilisé pour définir cette option pour désactiver les commandes:
```
git -c core.fileMode=false diff
```
Et la --global drapeau de rendre le comportement par défaut pour l'utilisateur connecté.
```
git config --global core.fileMode false
```
Changements de l'environnement planétaire ne sera pas appliqué pour les référentiels existants. Vous devez cloner le dépôt de nouveau ou d'exécuter git init. C'est sûr, sur les référentiels existants. Il ne remplace pas les choses qui sont déjà là.

Avertissement

core.fileMode n'est pas la meilleure pratique et doit être utilisée avec précaution. Ce paramètre ne couvre que le bit d'exécution de la mode et de ne jamais le lire/écrire des bits. Dans de nombreux cas, vous pensez que vous avez besoin de ce paramètre, car vous avez fait quelque chose comme chmod -R 777, de faire de tous vos fichiers exécutables. Mais dans la plupart des projets la plupart des fichiers n'ont pas besoin et ne devrait pas être exécutable pour des raisons de sécurité.

La bonne façon de résoudre ce genre de situation est de gérer le dossier et le fichier d'autorisation séparément, avec quelque chose comme:
```
find . -type d -exec chmod a+rwx {} \; # Make folders traversable and read/write
find . -type f -exec chmod a+rw {} \;  # Make files read/write
```
Si vous le faites, vous n'aurez jamais besoin d'utiliser core.fileMode, sauf dans de très rares environnement.
- Si vous ne git config --global core.filemode false vous aurez seulement besoin de le faire une fois pour toutes les pensions de titres.
- cela n'a pas fonctionné pour moi jusqu'à ce que j'ai résolu le cas, il devrait être fileMode au lieu de filemode
- Git section de configuration et les noms de variables sont insensible à la casse, selon la documentation, voir la section FICHIER de CONFIGURATION, donc si le ci-dessus ne fonctionne pas pour vous, alors c'était pour une raison différente.
- vrai. Aucune idée de ce qui est allé mal.
- Merci, j'ai été frapper ma tête pour savoir ce qui a changé dans mon projet. Un rapide git diff m'a dit sur les modes de commandement, de les ignorer. Merci Greg
- Si vous vous retrouvez dans la situation où vous devez modifier le fichier d'autorisation et de s'engager dans le git à partir d'une machine windows: blog.lesc.se/2011/11/how-to-change-file-premissions-in-git.html
- Ce n'est pas de travail pour moi :(, toutefois solution donnée par @Sinan Eldom a fonctionné pour moi. Mais c'est par la base du projet. Quelle est la solution globale pour elle.
- C'est tout beau, mais quel fichier de configuration n'cela aller?
- Le git config commande écrit le réglage pour le bon fichier de config (.git/config juste le référentiel actuel, ou ~/.gitconfig si utilisé avec --global).
- Merci. Peut-être serait utile d'ajouter que, pour la réponse à l'exhaustivité?
- Est-ce à ignorer les changements de mode lors de la validation? Il semble que samba ensembles de fichiers +x lors de l'enregistrement de windows. La mise en fileMode false faire une mise à jour de l'index si je commets il de toute façon? Ou est-ce juste valider les modifications du texte, mais pas le chmod des changements? Merci!
- Si elle ne fonctionne pas, essayez ceci: git filter-branch -f --tree-filter 'find * -type f | xargs chmod 644 ' -- --all
- J'ai dû git init pour cette config pour prendre effet.
- Après la récupération à partir d'un fichier endommagé le dépôt git de mes fichiers a la mauvaise autorisations. C'était mieux de se ré-ensemble au lieu de faire git ignorer: trouver . -type d | xargs chmod 0755 trouver . -type f | xargs chmod 0644 (stackoverflow.com/questions/14892289/...)
- filemode ou fileMode exactement?
- Il n'a pas d'importance. À partir de git config: "Les noms de variables sont sensibles à la casse, ..."
- même après avoir fait un changement global, il ne fonctionnera pas si le local config déjà eu filemode=True. Le local de la valeur de remplacer le paramètre par défaut... j'ai dû aller à toutes les pensions dans ma machine et le changement de valeur de configuration de filemode à faux pour chacune des locaux de repos
- j'ai essayé et échoué avec votre suggestion... Donc, je suis arrivé à vous.
- Oh wow, un flashback 2012... C'était le bon Greg, après tout.
- ouais... Postes sur l'internet n'ont pas de date d'expiration
- vous devez avoir créé un compte secondaire et upvoted votre post pour vous remercier.
- J'ai essayé la commande git config de base.fileMode faux et a fonctionné pour moi, merci pour le partage. Pour ceux que cela intéresse, il semble que ce paramètre n'est pas héréditaire, et doit être réappliqué si les pensions de titres sont inclus en tant que sous-module.
- Chaque fois que j'initialise un nouveau dépôt git (init), le paramètre est de retour à la "vraie" pour le nouveau repo.. (après avoir fait la commande git config --global core.filemode faux)
- Pour obtenir le fichier/autorisations de répertoire de travail sur OSX et ubuntu (j'ai été faire un find: unknown predicate '-t' erreur), j'ai dû changer à cela: find . -type d -exec chmod 755 {} \; et find . -type f -exec chmod 644 {} \;
- S'il vous PLAÎT ajouter un deuxième avertissement pour cette réponse, indiquant que le paramètre global ne sera pas appliqué à des repos! Pour chaque repo, vous devez exécuter la commande locale (ou il semble "git init" a le même effet). Cela va affecter tout le monde et peut être extrêmement déroutant (esp. lors de la première interaction avec un deuxième repo et n'ai aucune idée pourquoi le paramètre global ne fonctionne pas quand il a travaillé sur le premier dépôt, où vous avez exécuté à la fois global et local versions de la modification de paramètre.)
- Si j'utilise git config de base.sharedRepository vrai, alors j'ai besoin de changer fileMode?
- avec chmod vous pouvez utiliser +/-X tu modifier le fichier exécutable bits pour les dossiers, par exemple, chmod +X somefile est un noop, tandis que chmod +X somedir va définir le bit d'exécution est sur que dir
- La description a été modifiée et reflète le problème plus correctement maintenant core.fileMode ... Some filesystems lose the executable bit when a file that is marked as executable is checked out, or checks out an non-executable file with executable bit on. git-clone[1] or git-init[1] probe the filesystem to see if it handles the executable bit correctly and this variable is automatically set as necessary.
- La GRAISSE n'est pas "cassé" en ce sens, parce qu'évidemment il n'est pas conçu pour Unix, donc ne peut pas stocker de ces autorisations. Le même problème peut se produire en NTFS, exFAT ou en cas de montage par NFS... A repository, however, may be on a filesystem that handles the filemode correctly, and this variable is set to true when created, but later may be made accessible from another environment that loses the filemode (e.g. exporting ext4 via CIFS mount, visiting a Cygwin created repository with Git for Windows or Eclipse). In such a case it may be necessary to set this variable to false. See git-update-index[1].
- --global ne prendra effet récemment cloné dépôts.
- très rares environnement = vagrant sur ubuntu avec ubuntu? 🙁
- Je ne sais pas si le comportement a changé, mais core.fileMode est maintenant explicitement définie dans la par-repo git config sur clone. Donc git config --global core.filemode false comme suggéré dans le top commentaire n'aura aucun effet, car il est remplacé par le contexte local.
- Comme tous les autres git paramètres, le paramètre local remplace uniquement le mondial si elle est présente. Si non présent, le paramètre par défaut est utilisé. Voir man git-config.
- bien sûr, je voulais juste mettre en évidence que, contrairement à la plupart des autres paramètres (tels que autocrlf), le git binaire ensemble core.filemode localement pour chaque repo sur clone: git-clone ou git-init de la sonde du système de fichiers pour voir si il gère le bit d'exécution correctement et cette variable est automatiquement défini comme nécessaire.
- J'ai peut-être venu pour en revenir à cette ligne autour de 9876 fois, plus facile à trouver ce que de souvenir 🙂
- Dans notre environnement de production pour un client, l'index.php le fichier doit être 655. Le dev et la mise en scène, 755. J'ai donc mis le index.php à 655, déployé à la prod et dev. Fichier de jeu de perms à faux sur le dev, et il changé les permissions sur les dev à 755. Un réconcilié repo git avec des autorisations différentes!
InformationsquelleAutor Greg Hewgill
262

annuler le mode de changement dans l'arbre de travail:
```
git diff --summary | grep --color 'mode change 100755 => 100644' | cut -d' ' -f7- | xargs -d'\n' chmod +x
git diff --summary | grep --color 'mode change 100644 => 100755' | cut -d' ' -f7- | xargs -d'\n' chmod -x
```
Ou dans mingw-git
```
git diff --summary | grep  'mode change 100755 => 100644' | cut -d' ' -f7- | xargs -e'\n' chmod +x
git diff --summary | grep  'mode change 100644 => 100755' | cut -d' ' -f7- | xargs -e'\n' chmod -x
```
- Sur OS X Lion, omettre le -d'\n' partie de xargs que c'est un argument illégal (et n'est pas nécessaire).
- Vous pouvez ignorer les erreurs sur la commande "chmod: opérande manquant après `+x""
- Pascal: l'-d "\n" est nécessaire pour gérer les noms de fichiers avec des espaces; normal xargs des fentes sur les espaces.
- est-ce à jour? J'ai obtenu un chmod: trop peu d'arguments " dans mingw
- Le-d spécifie le séparateur d'être de retour à la ligne à la place de n'importe quel espace. BSD xargs n'ont pas cette option, mais au lieu de cela, vous pouvez rediriger la sortie à travers tr '\n' '\0' et ensuite utiliser le -0 arg à xargs à utiliser NUL comme délimiteur.
- Pour moi, il a donné chmod: missing operand after â+xâ
- Fonctionne pour moi pour le " bon " nom de fichier, mais échoue lorsqu'il y a des espaces dans les noms de fichiers (ipython les ordinateurs portables). Comment puis-je attraper ça?
- Cool, le tr chose a fonctionné! Voici l'intégralité de la commande pour OSX: git diff --summary | grep --color 'mode change 100644 => 100755' | cut -d' ' -f7-|tr '\n' '\0'|xargs -0 chmod -x
- Comment grep --color aider?
InformationsquelleAutor yoda
126

Si vous souhaitez définir cette option à tous pour votre repos, utilisez le --global option.
```
git config --global core.filemode false
```
Si cela ne fonctionne pas, vous êtes probablement à l'aide d'une version plus récente de git donc, essayez la --add option.
```
git config --add --global core.filemode false
```
Si vous l'exécuter sans l'option --global et votre répertoire de travail n'est pas un dépôt, vous obtiendrez
```
error: could not lock config file .git/config: No such file or directory
```
- Ne fonctionne pas pour moi sur la version git 1.7.9.6 (Apple Git-31.1)
- Ressemble à plus tard GIT utilise --add, comme dans git config --add --global core.filemode false
- Si le repo local de config a déjà filemode=vrai alors changer le mondial config ne va pas aider le local de la configuration de remplacer le fichier config. Devrez changer de local config de chaque pensions de la machine une fois
- S'il vous PLAÎT: mise à Jour de cette réponse avec syedrakib de l'avertissement! Tout était fou avant je l'ai trouvé, et tout à fait logique après.
InformationsquelleAutor adrien
74

Si
```
git config --global core.filemode false
```
ne fonctionne pas pour vous, faites-le manuellement:
```
cd into yourLovelyProject folder
```
cd dans .git dossier:
```
cd .git
```
éditer le fichier de configuration:
```
nano config
```
changement de true à false
```
[core]
        repositoryformatversion = 0
        filemode = true
```
->
```
[core]
        repositoryformatversion = 0
        filemode = false
```
enregistrer, quitter, allez à la partie supérieure du dossier:
```
cd ..
```
reinit le git
```
git init
```
vous êtes fait!
- Au lieu de modifier .git/config, une simple git config core.fileMode false à la racine de votre projet est assez. Si vous modifiez le fichier de configuration, vous êtes mieux de retrait de la directive entièrement, de sorte que le mondial est ramassé.
- -1 si git config --global ne fonctionne pas, cela signifie que vous n'avez pas les autorisations pour le faire au niveau du système, la suppression global option fait exactement la même chose que de modifier manuellement .git/config
- faux - la réponse dans la mesure d'une solution de contournement en mettant l'option directement dans le projet spécifique à un projet. Cela ne fonctionnera pas avec d'autres projets git que vous faites/de départ dans l'avenir, mais ne les travaux pour le projet sur lequel vous travaillez. (nous devons veiller à lever l'ambiguïté ~/.gitconfig, et ~/project/.git/config)
- Une fois que cela s'exécuter git init devrions-nous définir filemode retour à vrai?
InformationsquelleAutor Sinan Eldem
51

Ajoutant à Greg Hewgill répondre (de l'aide core.fileMode variable de config):

Vous pouvez utiliser --chmod=(-|+)x option de git mise à jour de l'index (bas niveau de la version de "git add") pour modifier les autorisations d'exécution dans l'index, d'où il sera ramassé si vous utilisez "git commit" (et pas "git commit-a").
- Ce qui devrait avoir été édité dans Greg Hewgill de la réponse plutôt que sur l'ajout comme une réponse distincte, formant ainsi un suprême de répondre avec un simple sans ambiguïté de la représentation.
- On a besoin d'avoir suffisamment de points pour modifier pas propre réponse; je pense que je n'ai pas assez pour les autorisations de modification à l'époque.
- Je pense que vous avez assez de réputation maintenant 🙂 et Quelle serait cette commande pour un exemple de fichier?
InformationsquelleAutor Jakub Narębski
35

Vous pouvez le configurer à l'échelle mondiale:

git config --global core.filemode false

Si le ci-dessus ne fonctionne pas pour vous, la raison pourrait être votre configuration locale remplace la configuration globale.

Supprimer votre configuration locale pour faire de la configuration globale de prise d'effet:

git config --unset core.filemode

Alternativement, vous pouvez changer votre configuration locale à la juste valeur:

git config core.filemode false
- Si la réponse ne vous aide pas - essayer celui-ci. Si vous voulez vérifier votre local config sans le modifier, vérifier git config -l (liste config actuelle - à la fois local et global)
InformationsquelleAutor Tyler Long
20

Si vous avez utilisé chmod commande déjà de vérifier ensuite la différence de fichier, Il affiche précédente en mode fichier et le fichier en cours mode de tels que:

nouvelle mode : 755

ancien mode de fonctionnement : 644

définir l'ancienne mode de tous les fichiers en utilisant la commande ci-dessous

sudo chmod 644 .

maintenant jeu de base.fileMode à false dans le fichier de configuration, soit à l'aide de la commande ou manuellement.
```
git config core.fileMode false
```
appliquer ensuite la commande chmod pour modifier les permissions de tous les fichiers tels que
```
sudo chmod 755 .
```
et à nouveau set de base.fileMode de vrai.
```
git config core.fileMode true
```
Pour les meilleures pratiques de ne pas Garder de base.fileMode faux toujours.
- Dites-vous que l'ensemble d'un projet (en cours d'élaboration, la mise en scène, et de la production) doit être 755?
- Février: Pas De. changer le mode des fichiers nécessaires seulement.
- For best practises don't Keep core.fileMode false always que voulez-vous dire, vous devez expliquer que.
- For best practises don't Keep core.fileMode false always. Certains systèmes de fichiers FAT (par exemple) ne prennent pas en charge les autorisations de fichier, de sorte que le système d'exploitation rapport à une valeur par défaut (766, sur mon système, de toute façon). Dans ce cas, core.filemode est absolument nécessaire dans les locaux de config, sauf si vous voulez gonfler le commettre l'histoire avec les inutiles et involontaire des modifications des autorisations
- Aussi, pourquoi ne vous dérange pas de changer la permanentes retour à tous? Si vous définissez core.filemode=false puis git va ignorer le bit d'exécution des changements, pas besoin de modifier les autorisations. Sauf si vous avez déjà ajouté des modifications des autorisations à l'index, dans lequel cas vous manque l'étape où vous auriez besoin de git add après désactivation de la core.filemode.
- Je me demandais ce qui se passe si j'ai cette situation (avec les permissions de modification) puis-je utiliser git config core.fileMode false. tandis que d'après la définition de ce que certains fichiers ne pourront pas être vu, tel que modifié (ceux qui ont seulement des modifications d'autorisations), mais d'autres avaient d'autres changements au-delà des autorisations d'e.g valide les modifications de code etc seront toujours considérés comme modifiés en raison des modifications de code. Si j'ai commis ces fichiers du mod changement également être commis dans le cadre d'elle?
- Non, si vous l'avez probablement déjà compris. Les seules choses qui sont engagés sont ce que vous étape pour la validation (c'est à dire les fichiers que vous git add, et les changements que vous voyez lorsque vous exécutezgit status)
InformationsquelleAutor Kishor Vitekar
16

Par definining l'alias (dans ~/.gitconfig), vous pouvez facilement désactiver temporairement le fileMode par commande git:
```
[alias]
nfm = "!f(){ git -c core.fileMode=false $@; };f"
```
Lorsque cet alias est précédé de la commande git, le fichier changements de mode de ne pas s'afficher avec des commandes qui seraient autrement leur montrer. Par exemple:
```
git nfm status
```
InformationsquelleAutor Ville
13

Si vous souhaitez définir filemode à faux dans la configuration des fichiers de manière récursive (y compris les submodules) :
find -name config | xargs sed -i -e 's/filemode = true/filemode = false/'
- Cela ne fonctionnera pas si la ligne n'est pas dans le fichier de configuration. Si vous souhaitez le changer pour submodules, essayez ceci: git submodule foreach git config core.fileMode false
InformationsquelleAutor dryobs
2

Solution Simple:

Hit de ce Simple commande dans le Dossier du projet(il ne supprimera pas les originaux de vos changements) ...il ne supprimer les modifications qui avait été fait alors que vous avez changé projet de dossier d'autorisation

de commande ci-dessous:

git config de base.fileMode faux

Pourquoi ce tous les fichiers inutiles obtenir modifié:
parce que vous avez changé le dossier du projet d'autorisations
avec félicite
sudo chmod -R 777 ./yourProjectFolder

quand allez-vous vérifier les modifications que vous pas fait?
vous avez trouvé comme ci-dessous lors de l'utilisation git diff nom de fichier
```
old mode 100644
new mode 100755
```
InformationsquelleAutor ngCourse
1

Cela fonctionne pour moi:
```
find . -type f -exec chmod a-x {} \;
```
ou l'inverse, selon votre système d'exploitation
```
find . -type f -exec chmod a+x {} \;
```
- Cela permettrait de changer les permissions du fichier, mais pas le faire à git d'ignorer les autorisations de fichier du fichier.
InformationsquelleAutor Martin Volek

Vous devez vous connecter pour publier un commentaire.

Avertissement