Si Git signale qu'un fichier est devenu exécutable — ou a cessé de l'être — sur votre Mac, identifiez d'abord quelle couche a changé : le fichier de travail, l'index de staging ou un commit. Comparez ces états avant de modifier les permissions ou la configuration Git. Git enregistre les fichiers normaux avec le mode 100644 (non exécutable) ou 100755 (exécutable) ; un changement isolé entre les deux pointe généralement vers le bit exécutable, et non vers une modification du contenu du fichier. Documentation de Git diff

1. Vérifier si la modification est indexée (staged)

Dans le Terminal, accédez au dépôt et inspectez son statut ainsi que les deux diffs :

git status --short
git diff --summary
git diff --cached --summary

git diff compare l'arbre de travail avec l'index ; git diff --cached compare l'index avec HEAD. Git status distingue ces mêmes couches, de sorte qu'une modification indexée apparaît séparément d'une modification non indexée. Documentation de Git status

Recherchez une sortie telle que mode change 100644 => 100755 path/to/file. Si elle n'apparaît que dans git diff --summary, le fichier de travail diffère de l'index. Si elle apparaît dans git diff --cached --summary, le changement de mode a été indexé et pourrait être commité. Si les deux sont vides mais qu'un coéquipier signale un changement commité, inspectez ensuite l'historique.

2. Comparer l'index avec le fichier sur Mac

Pour un chemin suivi, inspectez le mode enregistré dans l'index et les permissions actuelles du fichier :

git ls-files --stage -- "scripts/build.sh"
ls -l "scripts/build.sh"

Remplacez scripts/build.sh par le chemin exact relatif au dépôt ; mettez-le entre guillemets pour que les espaces et les caractères du shell soient traités littéralement. Dans la sortie de git ls-files --stage, le premier champ est le mode stocké dans l'index : 100644 signifie que Git n'enregistre pas le fichier comme exécutable, tandis que 100755 signifie qu'il l'est. La sortie de ls -l montre les bits de permission locaux ; un x dans un triplet de permissions indique une permission d'exécution pour cette catégorie d'utilisateur. La documentation de Git ls-files et le guide des permissions d'Apple expliquent ces deux vues.

Cette comparaison permet de cibler la cause. Si l'index indique 100644, mais que ls -l affiche une permission d'exécution, la divergence se trouve dans le fichier de travail (ou Git est configuré pour ignorer les différences de mode de fichier). Si l'index indique 100755, Git a déjà indexé ou extrait un mode exécutable, peu importe ce que vous vouliez pour ce fichier.

3. Trouver le commit à l'origine du mode

Si le changement est déjà présent dans l'historique, examinez les résumés des commits du fichier concerné :

git log --summary -- "scripts/build.sh"

Le format de patch de Git affiche des en-têtes distincts old mode et new mode lorsque le mode d'un fichier change. Examinez le commit où ces valeurs basculent, puis comparez son parent et le flux de travail environnant : le fichier a-t-il été délibérément rendu exécutable, un éditeur ou un script a-t-il modifié les permissions, ou le dépôt a-t-il été utilisé sur un autre système de fichiers ou d'exploitation ? Le commit indique le moment où Git a enregistré le changement ; il ne prouve pas quelle application ou quelle personne en est à l'origine. Documentation sur le format diff de Git

Un changement de mode touchant plusieurs fichiers non liés peut indiquer une opération globale de définition des permissions ou une transition de système de fichiers/d'environnement. Git documente que certains systèmes de fichiers ne préservent pas les bits exécutables, et qu'un dépôt déplacé d'un environnement à un autre peut présenter des comportements de mode de fichier différents. Considérez cela comme un indice à explorer, et non comme la preuve d'une cause précise. Documentation de la configuration Git

4. Vérifier le paramètre de mode de fichier de Git

Vérifiez le paramètre et son origine :

git config --show-origin --get core.filemode

core.filemode contrôle si Git prend en compte les différences de bit exécutable dans l'arbre de travail. Git lui attribue la valeur true par défaut lorsqu'il n'est pas spécifié et peut sonder le comportement du système de fichiers lorsqu'un dépôt est initialisé ou cloné. Si la commande renvoie false, Git peut ignorer les modifications locales du bit exécutable ; ce paramètre n'explique pas un mode déjà enregistré dans un commit. S'il n'affiche rien, l'option n'est peut-être pas définie, auquel cas la valeur par défaut documentée de Git s'applique. Documentation de la configuration Git

Évitez de définir cette option sur false simplement pour masquer un diff inattendu. Confirmez d'abord si le dépôt se trouve sur un système de fichiers ou une configuration partagée qui ne préserve pas fidèlement les bits exécutables, et si vos collaborateurs comptent sur le suivi des modes. Modifier ce paramètre change la façon dont Git gère les différences de mode ; cela ne répare pas un mode mal enregistré dans l'index ou dans un commit.

5. Réparer uniquement après avoir identifié le mode souhaité

Si le fichier ne doit pas être exécutable et que la modification n'est pas indexée, restaurez la permission locale avec chmod :

chmod a-x "scripts/build.sh"
git diff --summary

Si le mode prévu est exécutable, utilisez plutôt chmod a+x "scripts/build.sh". Sur macOS, chmod modifie les permissions de l'élément spécifié ; choisissez le mode prévu en fonction du rôle du fichier et des conventions du dépôt, et non simplement pour faire disparaître le diff. Guide des permissions d'Apple

Si un mode incorrect est indexé, définissez la permission locale souhaitée, puis indexez à nouveau ce chemin et vérifiez le résumé indexé :

chmod a-x "scripts/build.sh"
git add -- "scripts/build.sh"
git diff --cached --summary

Utilisez a+x à la place de a-x lorsque le fichier doit être exécutable. Si le mode est incorrect dans un commit existant, un nouveau commit correctif est généralement plus clair que la réécriture d'un historique partagé ; coordonnez-vous avec votre équipe avant de réécrire des commits que d'autres personnes pourraient déjà utiliser. Dans tous les cas, inspectez git diff et git diff --cached ensuite afin de ne pas omettre de modifications de contenu en même temps que le changement de permission.

Sources