Git chmod problem: Checkout vis exec bit

10

Sous Ubuntu et Debian, les derniers fichiers validés obtiennent le bit d'exécution défini, lorsque j'essaie une vérification par la suite. C'est assez étrange et ça me rend dingue:

$ ls -l file
-rw-r--r-- ... file

# on branch master:
$ git commit -m 'mode is 644' file
[master 0123456] mode is 644
 1 files changed, 1 insertions(+), 1 deletions(-)
# All ok

$ git checkout dev-branch
Switched to branch 'dev-branch'
# Seemingly all ok, but file now has the exec bit set

$ git merge master
Updating 6543210..0123456
error: Your local changes to 'file' would be overwritten by merge.  Aborting.
Please, commit your changes or stash them before you can merge.
# Oops...

$ ls -l file
-rwxr-xr-x ... file

Quelqu'un at-il une idée, quand et pourquoi le bit d'exécution se glisse? core.filemodeest défini sur true.

J'ai le fichier ouvert dans vim pendant le changement de branche, si c'est important d'une manière ou d'une autre.

Addendum 1: C'est la caisse, où les autorisations sont vissées. Je peux jouer au jeu indéfiniment:

$ git br
* master
  dev-branch

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

$ chmod 644 file

$ git diff

$ git checkout dev-branch

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

$ chmod 644 file

$ git diff

$ git checkout master

$ git diff
diff --git a/file b/file
old mode 100644
new mode 100755

# ...and so on ad inf.

Addendum 2: Cela se produit, en passant, pour chaque fichier dans ce référentiel, que je valide. Après la validation réussie, je ne peux pas changer de branche sans la permission.

Boldewyn
la source
Avez-vous vérifié les autorisations à l'étape #seemingly all ok ...
RobotHumans
Je suis d'accord ici. Sur dev-branch, 'git-log master ... HEAD - file' et voyez si quelque chose a changé entre la branche et maintenant sur ce fichier.
yuriismaster
@ aking1012: Oui, à ce stade, les modes de fichier ont déjà changé. Je mettrai à jour la question.
Boldewyn
@yuriismaster: git-logne montre aucune sortie du tout, pour aucune combinaison de master, dev-branchou HEAD(ce qui est étrange, n'est-ce pas? La commande ne devrait-elle pas imprimer le dernier message de validation de master?)
Boldewyn
2
Sur quel système de fichiers êtes-vous?
bitmask

Réponses:

12

Pas un utilisateur Git, mais je pense que Git stocke l'intégralité du masque d'autorisation de fichier.

Cela signifie que vous avez défini le fichier sur exécutable, que Git a récupéré et répliqué dans le référentiel. Par conséquent, vous devez modifier le masque d'autorisation du fichier lui-même avant de valider.

Pour que Git ignore ces modifications, utilisez

git config core.filemode false

Depuis git-config (1) :

   core.fileMode
       If false, the executable bit differences between the index and the
       working copy are ignored; useful on broken filesystems like FAT.
       See git-update-index(1). True by default.
harrymc
la source
1
En fait, je m'efforce de valider les fichiers avec les autorisations appropriées. J'ai même réengagé tous les fichiers après les avoir modifiés. Comme je travaille de temps en temps sur Windows (mais pas avec ce dépôt), je le sais core.fileMode, mais j'espérais pouvoir le quitter true.
Boldewyn
Cela pourrait même être un bug dans git lorsque vous travaillez sur ce qu'ils appellent des "systèmes de fichiers cassés". Il n'y a pas de systèmes de fichiers cassés, seulement des logiciels cassés.
harrymc
4
je dois être d'accord avec les développeurs git que la graisse est cassée
RobotHumans
3
OK, c'était le système de fichiers. Je n'ai pas pu le reproduire sur une autre machine, où le répertoire est monté via NFS. Sur la machine principale, il s'agit, comme je l'ai dit, de CIFS. Quand j'ai demandé sur la liste de diffusion git, j'ai obtenu la réponse, que CIFS est cassé concernant les bits d'exécution. Zut!
Boldewyn
3

Avez-vous vérifié s'il existe un hook personnalisé qui est exécuté lors de la validation ou de l'extraction? Il peut y avoir des crochets personnalisés altérant vos fichiers. Extrayez le githooks manpage .

Les hooks sont fondamentalement de petits programmes appelés par git lors de certains événements (commit, checkout etc.).

bandi
la source
Bon essai, mais mon .git/hooksrépertoire est intact.
Boldewyn
1

avez-vous essayé git commit -m 'mode is 644' file on branch dev-branch

pour moi, il semble que ce qui se passe, c'est que vous modifiez les autorisations sur le principal, puis que vous tiriez vers le bas la branche de développement qui a la mauvaise autorisation, encombrant votre autorisation locale. puis essayez de vous engager à nouveau. soit cloner, modifier, valider, fusionner; ou essayez de changer le fichier individuellement avec une seule validation de fichier dans dev puis fusionnez

RobotHumains
la source
1
En fait, je ne touche jamais aux autorisations dans le scénario d'origine. Tous les changements de permission sont effectués par git dans l'étape 'checkout'.
Boldewyn
... c'est-à-dire que j'ai fait une chmodfois une ing sur les fichiers, mais je ne me souviens malheureusement pas si le problème a commencé à se produire juste après. Je pense que non.
Boldewyn
j'ai essayé de vous reproduire le problème et je ne peux pas
RobotHumans
C'est parce que vous ne travaillez pas sur un CIFS monté ;-). J'ai oublié le +1 pour l'essai, merci!
Boldewyn