Fichiers affichés comme modifiés directement après un clone Git


228

J'ai un problème avec un référentiel pour le moment, et bien que mon Git-fu soit généralement bon, je n'arrive pas à résoudre ce problème.

Lorsque je clone ce référentiel, puis cddans le référentiel, git statusaffiche plusieurs fichiers modifiés. Remarque: Je n'ai ouvert le référentiel dans aucun éditeur ou quoi que ce soit.

J'ai essayé de suivre ce guide: http://help.github.com/dealing-with-lineendings/ , mais cela n'a pas aidé du tout avec mon problème.

J'ai essayé git checkout -- .plusieurs fois, mais cela ne semble rien faire.

Je suis sur un Mac et il n'y a pas de sous-modules dans le référentiel lui-même.

Le système de fichiers est un système de fichiers "Journaled HFS +" sur Mac et n'est pas sensible à la casse. Les fichiers sont sur une seule ligne et environ 79 Ko chacun (oui, vous avez bien entendu), donc regarder git diffn'est pas particulièrement utile. J'ai entendu parler de fairegit config --global core.trustctime false qui pourrait aider, que j'essaierai lorsque je reviendrai à l'ordinateur avec le référentiel dessus.

J'ai changé les détails du système de fichiers avec des faits! Et j'ai essayé l' git config --global core.trustctime falseastuce qui n'a pas très bien fonctionné.

Réponses:


142

J'ai eu le même problème sur le Mac après le clonage d'un référentiel. Cela supposerait que tous les fichiers ont été modifiés.

Après l'exécution git config --global core.autocrlf input, il marquait toujours tous les fichiers comme modifiés. Après avoir cherché un correctif, je suis tombé sur un .gitattributesfichier dans le répertoire personnel qui présentait les éléments suivants.

* text=auto

Je l'ai commenté et tous les autres dépôts clonés fonctionnent désormais correctement.


5
Merci! J'ai finalement trouvé cela après avoir passé toute la soirée à basculer core.autocrlf et apply.whitespace. Cela a fonctionné. Je vous remercie.
xer0x

5
La ligne incriminée dans .gitattributes provenait des fichiers dot de Mathias Bynen , au cas où quelqu'un d'autre tomberait dessus .
SeanPONeil

31
quelqu'un peut-il faire la lumière sur cette configuration particulière? Que fait * text=auto-il? Que signifie le supprimer .gitattributes? Je vois que cela résout ce problème pour moi, mais je ne sais pas pourquoi il le fait, et ce qu'il fait vraiment, et quels problèmes possibles cela peut-il créer?
Dennis

6
@Dennis Ce paramètre permet de normaliser les fins de ligne, donc sa suppression n'est probablement pas la bonne réponse. Voir cette question de réponse et cet article . La réponse de @Arrowmaster ci-dessous m'a été plus utile. J'ai utilisé git addet git commitqui a normalisé le fichier et éliminé le problème.
jtpereyda

4
git config --global core.autocrlf inputréparé pour moi. Merci.
dimiguel

89

J? ai compris. Tous les autres développeurs sont sur Ubuntu (je pense) et ont donc des systèmes de fichiers sensibles à la casse. Moi non plus (comme je suis sur un Mac). En effet, tous les fichiers avaient des jumeaux minuscules lorsque je les ai regardés en utilisant git ls-tree HEAD <path>.

Je vais demander à l'un d'eux de régler le problème.


L'ont-ils jamais réglé? J'ai peut-être le même problème.
Josh Johnson

8
Oui, demandez simplement à quelqu'un avec un système de fichiers sensible à la casse de supprimer tous les fichiers sauf un de chaque ensemble de fichiers qui auraient des noms de fichiers en double sur un système de fichiers ne respectant pas la casse.
Sam Elliott

1
Je viens de rencontrer le même problème depuis le passage d'Ubuntu à Mac. Merci, votre réponse a mis le doigt sur la tête. J'espère que le vote positif le poussera à la première position. :-)
chmac

1
@Dirk c'est pourquoi il y a plusieurs réponses. J'ai accepté celui qui s'appliquait dans mon cas, ce qui n'est pas déraisonnable.
Sam Elliott

1
C'était aussi mon problème - MacOS insensible à la casse. Cependant, git ls-tree HEAD <path>n'a montré qu'un seul fichier. Cependant, j'ai pu voir les fichiers en double dans l'interface utilisateur de GitHub.com et également utiliser cette interface pour supprimer une version.
orion elenzil

74
git config core.fileMode false

résolu ce problème dans mon cas

https://git-scm.com/docs/git-config

TL; DR;

core.fileMode

Si false, les différences de bits exécutables entre l'index et l'arborescence de travail sont ignorées; utile sur les systèmes de fichiers cassés comme FAT. Voir git-update-index (1).

La valeur par défaut est true, sauf que git-clone (1) ou git-init (1) va sonder et définir core.fileMode false le cas échéant lorsque le référentiel est créé.


2
Mais qu'est-ce que cela fait ??
Siwel

1
J'aimerais aussi savoir ce que cela fait, car cela a également fonctionné pour moi.
Donato

2
Quand je l'ai fait git diff, j'ai constaté que les modifications étaient uniquement en mode fichier. git reprend ce chmod -R 777 .qui a été causé lorsque j'ai exécuté mon projet et cette configuration m'a permis d'ignorer les modifications de chmod par git stackoverflow.com/q/1580596/6207775
Ayushya

1
Le lien est rompu ( "Désolé, nous n'avons pas trouvé vos noyaux" ).
Peter Mortensen

Le reste des réponses n'a pas fonctionné, cela a cependant fait la magie!
Rencontrez Patel

53

Je suppose que vous utilisez Windows. Cette page GitHub à laquelle vous avez lié a les détails à l'envers. Le problème est que les terminaisons de ligne CR + LF ont déjà été validées dans le référentiel et parce que core.autocrlf est défini sur true ou input , Git veut convertir les terminaisons de ligne en LF, doncgit status qui montre que chaque fichier est modifié.

S'il s'agit d'un référentiel auquel vous souhaitez uniquement accéder, mais sans implication, vous pouvez exécuter la commande suivante pour masquer simplement le problème sans le résoudre.

git config core.autocrlf false

S'il s'agit d'un référentiel dans lequel vous serez activement impliqué et auquel vous pourrez valider des modifications. Vous pouvez résoudre le problème en effectuant une validation qui modifie toutes les fins de ligne dans le référentiel pour utiliser LF au lieu de CR + LF, puis prendre des mesures pour éviter que cela ne se reproduise à l'avenir.

Ce qui suit est tiré directement de la page de manuel gitattributes et doit être préformé à partir d'un répertoire de travail propre.

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force Git to
git reset         # re-scan the working directory.
git status        # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

Si des fichiers qui ne doivent pas être normalisés apparaissent dans git status, désactivez leur attribut de texte avant de l'exécuter git add -u.

manual.pdf      -text

Inversement, la normalisation des fichiers texte que Git ne détecte pas peut être activée manuellement.

weirdchars.txt  text

8
Je n'utilise pas de fenêtres.
Sam Elliott

1
Par défaut sur les systèmes non Windows, core.autocrlf est défini sur false. Vous ne devriez donc même pas avoir rencontré ce problème s'il est causé par des fins de ligne. Pourriez-vous donner plus de détails sur votre configuration spécifique, comme ce qui git diffs'affiche pour les fichiers qui git statussont modifiés, ainsi que le système de fichiers que vous utilisez?
Arrowmaster

mis à jour la question avec des réponses à ces questions. Jettera un autre regard sur tous les détails dans une seconde ou deux. Je ne sais pas ce que les autres membres de l'équipe de développement utilisent
Sam Elliott

C'est ce qui a fonctionné pour nous ( git config core.autocrlf falseétait suffisant). Nous avons été trompés par le fait que le client fonctionne sous Linux (SL / RHEL), mais la session Linux est lancée via x2go à partir d'un hôte Windows. C'est donc peut-être la solution la plus probable dans un contexte homogène Win + Lin.
Dirk

37

Veuillez exécuter les commandes suivantes. Cela pourrait résoudre le problème.

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Aucune des autres solutions n'a fonctionné pour moi, mais celle-ci m'a remis en marche.
rainabba

1
J'ai essayé celui-ci et cela a fonctionné pour moi. Merci M. LIama!
Danniel Little

Cela aggrave mon référentiel. Sur une branche qui n'a pas changé, j'en avais 277 après l'avoir exécutée. J'ai eu ces mêmes changements sur d'autres branches où je suis également passé. Courez avec prudence. Je viens de recloner par repo et j'ai modifié 615 fichiers. :(
Programmeur Paul

cela a fonctionné pour moi en utilisant git v2.7.4 avec ubuntu (WSL), Git pour Windows v2.18.0.windows.1 et posh-git J'ai toujours eu autocrlf false et le problème a commencé dans Git pour Windows et posh-git après la mise à niveau vers 2.18.0 aujourd'hui
Jim Frenette

Je suis étonné que cela fonctionne. Merci pour l'aide. Pour d'autres qui empruntent ce chemin, les fichiers qui ont apparemment été modifiés étaient tous des fichiers .png et .bmp gérés par git LFS
David Casper

16

Dans Visual Studio, si vous utilisez Git, vous pouvez générer automatiquement les fichiers .gitignore et .gitattributes. Le fichier .getattributes généré automatiquement a la ligne suivante:

* text=auto

Cette ligne se trouve vers le haut du fichier. Nous avions juste besoin de commenter la ligne en ajoutant un # à l'avant de celle-ci. Après cela, les choses ont fonctionné comme prévu.


1
Merci, je me bats avec ça pour les prix
Andrew Berry

C'était exactement mon problème. Un autre développeur avait utilisé GIT via VS au lieu de CLI et avait créé ce fichier .gitattributes.
Josh Maag

12

Le problème peut également provenir de différentes autorisations de fichier , comme c'était mon cas:

Nouveau référentiel cloné (Windows, Cygwin):

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Dépôt à distance nu (Linux):

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

5

Je voulais ajouter une réponse plus orientée sur "Pourquoi" cela se produit, car il existe déjà une bonne réponse sur la façon de le corriger.

Donc, .gitattributesa un * text=autoparamètre, qui provoque ce problème.

Dans mon cas, les fichiers de la branche principale de GitHub avaient une \r\nfin. J'ai composé les paramètres du référentiel pour m'enregistrer avec les \nterminaisons. Je ne sais pas ce que Git vérifie cependant. Il est censé extraire avec des terminaisons natives sur ma boîte Linux ( \n), mais je suppose qu'il a extrait le fichier avec des \r\nterminaisons. Git se plaint car il voit les \r\nterminaisons extraites qui étaient dans le référentiel et m'avertit qu'il archivera les \nparamètres. Les fichiers doivent donc "être modifiés".

C'est ma compréhension pour l'instant.


4

Le même problème pour moi. Je pouvais voir plusieurs images du même nom, comme "textField.png" et "textfield.png" dans le référentiel Git distant, mais pas sur mon référentiel local. Je n'ai pu voir que "textField.png" qui n'était pas utilisé dans le code du projet.

Il s'avère que la plupart de mes collègues utilisent Ubuntu avec ext4 système de fichiers alors que je suis sur un Mac en utilisant APFS.

Merci à Sam Elliott la réponse , la solution était assez simple. J'ai d'abord demandé à un collègue sur Ubuntu de supprimer les versions de fichiers redondantes avec les majuscules, puis de valider et de pousser à distance.

Ensuite, j'ai exécuté ce qui suit:

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Enfin, nous avons décidé que chaque développeur devrait modifier sa configuration Git pour éviter que cela ne se reproduise:

# Local Git configuration
git config core.ignorecase = true

ou

# Global Git configuration
git config --global core.ignorecase = true

Ce serait mieux si vous venez upvotedde répondre à @ kds !
Elharony

Il semble que la commande en ligne de commande ne devrait pas avoir le signe égal ( =) car elle se retrouvera ignorecase = =dans le fichier de configuration.
Dmytro

3

J'ai eu le même problème. Également avec un Mac. En regardant le référentiel sur une machine Linux, j'ai remarqué que j'avais deux fichiers:

geoip.dat et GeoIP.dat

J'ai supprimé celui obsolète sur la machine Linux et cloné à nouveau le référentiel sur le Mac. Je n'ai pas pu extraire, valider, cacher ou extraire de ma copie du référentiel lorsqu'il y avait des doublons.


1

J'ai aussi juste eu le même problème. Dans mon cas, j'ai cloné le référentiel et certains fichiers étaient immédiatement manquants.

Cela était dû au chemin d'accès au fichier et au nom de fichier trop long pour Windows. Pour le résoudre, clonez le référentiel le plus près possible de la racine du disque dur afin de réduire la longueur du chemin d'accès au fichier. Par exemple, clonez-le à la C:\A\GitRepoplace de C:\Users Documents\yyy\Desktop\GitRepo.


1

Modifiez le fichier appelé .git/config:

sudo gedit .git/config

Ou:

sudo vim .git/config

Contenu

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
    remote = origin
    merge = refs/heads/master

[branch "productapproval"]
    remote = origin
    merge = refs/heads/productapproval

Changez filemode=trueen filemode = false.


Cela équivaut àgit config core.Filemode false
Guillermo Prandi

1

Pour les nouvelles versions de macOS, cela peut être dû à une fonction de sécurité du système d'exploitation.

Dans le référentiel sur lequel je travaillais, il y avait un fichier binaire qui avait * .app comme type de fichier.

Il ne s'agissait que de données sérialisées, mais macOS traite tous les fichiers * .app comme une application et comme ce fichier n'a pas été téléchargé par l'utilisateur, le système l'a jugé non sécurisé et a ajouté le com.apple.quarantine attribut file qui garantit que le fichier ne peut pas être exécuté.

Mais la définition de cet attribut sur le fichier modifiait également le fichier et il apparaissait donc dans l'ensemble de modifications Git sans aucun moyen de le rétablir.

Vous pouvez vérifier si vous rencontrez le même problème en exécutant $ xattr file.app.

La solution est assez simple, tant que vous n'avez pas à travailler avec le fichier. Ajoutez simplement *.app binaryà votre .gitattributes.


0

J'ai copié mon référentiel local dans un autre dossier et un tas de fichiers modifiés est apparu. Ma solution de contournement était la suivante: j'ai caché les fichiers modifiés et supprimé la cachette . Le référentiel est devenu propre.


0

J'ai trouvé que Git traitait mes fichiers (.psd dans ce cas) comme du texte. La définition d'un type binaire dans les .gitattributes l'a résolu.

*.psd binary

0

J'essayais de faire un rebase interactif, mais il a prétendu qu'il y avait des fichiers modifiés, donc il ne m'a pas laissé le faire maintenant. J'ai tout essayé pour revenir à un référentiel propre, mais rien n'a fonctionné. Aucune des autres réponses n'a aidé. Mais cela a finalement fonctionné ...

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

Boom! Référentiel propre. Problème résolu. Ensuite, j'ai juste dû abandonner le dernier commit quand j'ai fait mon rebase -iet finalement tout était à nouveau propre. Bizarre!


0

Juste au cas où cela aiderait quelqu'un d'autre, il peut y avoir une autre cause à ce problème: les différentes versions de Git. J'utilisais la version installée par défaut de Git sur une boîte Ubuntu 18.04 (Bionic Beaver) et tout fonctionnait bien, mais lorsque j'essayais de cloner le référentiel à l'aide de Git sur Ubuntu 16.04, certains fichiers apparaissaient comme modifiés.

Aucune des autres réponses ici n'a résolu mon problème, mais la mise à niveau des versions de Git pour correspondre sur les deux systèmes a résolu le problème.


1
Il serait utile (et intéressant) de savoir quelles versions de git ne fonctionnaient pas bien ensemble.
jpaugh
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.