Fichiers affichés comme modifiés directement après le clone de git

J’ai un problème avec un repository 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 repository, puis cd dans le repository, git-status affiche plusieurs fichiers modifiés. Note: Je n’ai pas ouvert le repo dans un éditeur ou quoi que ce soit d’autre.

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

J’ai essayé la git checkout -- . plusieurs fois mais il ne semble rien faire.

Toute aide / idée serait grandement appréciée

Mise à jour 1: Je suis sur un mac, et il n’ya pas de sous-module dans le repository même.

Mise à jour 2: le système de fichiers est le système de fichiers “Journaled HFS +” sur le mac, et n’est pas sensible à la casse. Les fichiers sont à une ligne et environ 79K chacun (oui, vous avez bien entendu), donc regarder git diff n’est pas particulièrement utile. J’ai entendu parler de faire git config --global core.trustctime false ce qui pourrait aider, que je vais essayer quand je reviendrai sur l’ordinateur avec le référentiel.

Mise à jour 3: modification des détails du système de fichiers avec les faits! et, j’ai essayé le git config --global core.trustctime false tour qui ne fonctionnait pas très bien.

J’ai eu le même problème sur le Mac après avoir cloné un repository, cela suppose que tous les fichiers ont été modifiés.

Après avoir exécuté l’ git config --global core.autocrlf input tous les fichiers étaient toujours modifiés. Après avoir recherché un correctif, je suis tombé sur .gitatsortingbutes fichier .gitatsortingbutes dans le répertoire de base qui .gitatsortingbutes les éléments suivants.

 * text=auto 

Je l’ai commenté et tous les autres repositorys clonés fonctionnent désormais correctement. J’espère que cela aide quelqu’un là-bas.

Je l’ai. Tous les autres développeurs sont sur Ubuntu (je pense) et ont donc des systèmes de fichiers sensibles à la casse. Je n’ai cependant pas (comme je suis sur un mac). En fait, tous les fichiers avaient des minuscules lorsque je les regardais en utilisant git ls-tree HEAD .

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

 git config core.fileMode false 

résolu ce problème dans mon cas

https://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/git-config.html

TL; DR;

core.fileMode

Si la valeur est 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) parsingra et définira core.fileMode false si nécessaire lors de la création du référentiel.

Je suppose que vous utilisez Windows. Cette page github que vous avez liée a les détails en arrière. Le problème est que les fins de ligne CRLF ont déjà été validées sur repo et que core.autocrlf est défini sur true ou sur input , git veut convertir les fins de ligne en LF pour que l’ git status indique que chaque fichier est modifié.

S’il s’agit d’un repo auquel vous ne souhaitez accéder que si vous n’avez aucune implication, vous pouvez exécuter la commande suivante pour simplement masquer le problème sans le résoudre.

 git config core.autocrlf false 

S’il s’agit d’un repo auquel vous participerez activement et pourrez y apporter des modifications. Vous voudrez peut-être résoudre le problème en effectuant un commit qui modifie toutes les fins de ligne dans le repo pour utiliser LF au lieu de CRLF, puis prendre des mesures pour éviter qu’il ne se reproduise à l’avenir.

Ce qui suit provient directement de la page de manuel gitatsortingbutes et doit être préformé à partir d’un répertoire de travail propre.

 echo "* text=auto" >>.gitatsortingbutes 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 .gitatsortingbutes git commit -m "Introduce end-of-line normalization" 

Si des fichiers ne devant pas être normalisés apparaissent dans l’état git, désactivez leur atsortingbut textuel avant d’exécuter git add -u .

 manual.pdf -text 

Inversement, la normalisation peut être activée manuellement pour les fichiers texte que git ne détecte pas.

 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 .gitatsortingbutes. Le fichier .getatsortingbutes généré automatiquement a la ligne suivante:

 * text=auto 

Cette ligne est près du haut du fichier. Nous avions juste besoin de commenter la sortie en ajoutant un # à l’avant. Après cela, les choses ont fonctionné comme prévu.

Le problème peut également provenir de différentes permissions de fichiers , comme ce fut mon cas:

Référentiel cloné frais (Windows, Cygwin):

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

Référentiel à distance nue (Linux):

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

J’ai eu le même problème. Aussi avec un Mac. En regardant le repo sur une machine Linux, j’ai remarqué que j’avais deux fichiers:

geoip.dat et GeoIP.dat

Supprimé le déprécié sur la machine Linux et cloné à nouveau le référentiel sur le mac. Je n’ai pas pu extraire, valider, ranger ou extraire de ma copie du référentiel en cas de doublons.

Je voulais append une réponse plus ciblée sur “Pourquoi” cela se produit, car il existe déjà une bonne réponse sur la façon de résoudre ce problème.

Ainsi, .gitatsortingbutes a un paramètre * text=auto , ce qui provoque ce problème.

Dans mon cas, les fichiers de la twig principale de GitHub avaient des fins \r\n . J’ai composé les parameters du repo pour enregistrer avec \n fins. Je ne sais pas ce que git vérifie cependant. Il est supposé vérifier avec des terminaisons natives sur ma boîte Linux ( \n ), mais je suppose qu’il a extrait le fichier avec les fins \r\n . Git se plaint car il voit les terminaisons \r\n extraites qui se trouvaient dans le repo et m’avertit qu’il vérifiera les parameters \n . Les fichiers sont donc “à modifier”.

C’est ma compréhension pour le moment.

Je viens aussi d’avoir le même problème. Dans mon cas, j’ai cloné le repository et certains fichiers manquaient immédiatement.

Cela a été causé par le chemin d’access au fichier et le nom de fichier étant 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’access au fichier. Par exemple, clonez-le dans C: \ A \ GitRepo au lieu de C: \ Users Documents \ yyy \ Desktop \ GitRepo

Modifier le fichier appelé: sudo gedit .git/config sudo vim .git/config

 [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 

Modifier filemode = true en filemode = false

J’ai copié mon référentiel local dans un autre dossier et un tas de fichiers modifiés ont été affichés. Ma solution de contournement était la suivante: j’ai caché les fichiers modifiés et supprimé le cache . 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 binary dans les atsortingbuts .git l’a résolu.

 *.psd binary 

J’avais un problème similaire et j’ai trouvé cette question.

J’essayais de faire un rebase interactif, mais il a prétendu qu’il y avait des fichiers modifiés, donc cela ne me laisserait pas le faire maintenant. J’ai essayé tout pour revenir à un repo 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! Repo propre. Problème résolu. Ensuite, j’ai dû abandonner le dernier engagement lorsque j’ai effectué mon rebase -i et finalement tout était à nouveau propre. Bizarre!

Mais j’ajoute cette solution ici, pour que peut-être si je retombe dans ce cas, je le verrai et l’essayerai. Merci: D