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

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é.

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.

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.

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éé.

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

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

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.

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
   ↑↑↑

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.

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

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.

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.

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.

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.

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.

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

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!

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.