Fichiers affichés comme modifiés directement après le clone git
J'ai un problème avec un dépôt en ce 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 cd dans le référentiel, git-status affiche plusieurs fichiers modifiés. Remarque: je n'ai ouvert le référentiel dans aucun éditeur ni quoi que ce soit.
J'ai essayé de suivre ce guide: http://help.github.com/dealing-with-lineendings/ mais cela ne m'a pas aidé du tout avec mon problème.
J'ai essayé plusieurs fois git checkout -- . mais il semble que rien ne soit fait.
Toute aide/idées serait grandement appréciée
Mise à jour 1: Je suis sur un Mac et il n'y a pas de sous-modules dans le repo lui-même.
Mise à jour 2: le système de fichiers est un système de fichiers "Journaled HFS +" sur le Mac et ne respecte pas la casse. Les fichiers sont d’une ligne et pèsent chacun environ 79 000 $ (oui, vous avez bien entendu), il n’est donc pas très utile de consulter git diff. J'ai entendu parler de git config --global core.trustctime false qui pourrait aider, et que j'essaierai quand je reviens à l'ordinateur avec le dépôt.
Mise à jour 3: a modifié les détails du système de fichiers avec les faits! et j’ai essayé l’astuce git config --global core.trustctime false qui ne fonctionnait pas très bien.
J? ai compris. Tous les autres développeurs sont sur Ubuntu (je pense) et ont donc des systèmes de fichiers sensibles à la casse. Cependant, je ne le fais pas (car je suis sur un mac). En effet, tous les fichiers avaient des jumeaux minuscules lorsque je les ai examinés en utilisant git ls-tree HEAD <path>.
Je vais demander à l'un d'entre eux de le régler.
J'ai eu le même problème sur le Mac après le clonage d'un repo, cela supposerait que tous les fichiers ont été modifiés.
Après avoir exécuté git config --global core.autocrlf input, tous les fichiers étaient encore marqués comme modifiés. Après avoir cherché un correctif, je suis tombé sur le fichier .gitattributes dans le répertoire de base qui contenait les éléments suivants.
* text=auto
Je l'ai commenté et tous les autres référentiels clonés fonctionnent désormais correctement. J'espère que cela aide quiconque.
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 entre les bits exécutables entre l'index et l'arbre 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) sondera et définira core.fileMode sur 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 dans le référentiel et que core.autocrlf étant défini sur true ou input, git souhaite convertir les fins de ligne en LF donc git status indique que chaque fichier est modifié.
S'il s'agit d'un référentiel auquel vous souhaitez uniquement accéder mais que vous n'avez aucune implication, vous pouvez exécuter la commande suivante pour simplement masquer le problème sans le résoudre réellement.
git config core.autocrlf false
S'il s'agit d'un référentiel auquel vous participerez activement et sur lequel vous pourrez valider des modifications. Vous voudrez peut-être résoudre le problème en faisant un commit qui modifie toutes les fins de ligne du référentiel pour utiliser LF au lieu de CRLF, 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 vierge.
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 l'état git, désactivez leur attribut text avant d'exécuter git add -u.
manual.pdf -text
Inversement, la normalisation peut être activée manuellement dans 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 .gitattributes. Le fichier .getattributes 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 ligne en ajoutant un # au début. Après cela, les choses se sont déroulées comme prévu.
Le problème peut également provenir de file permissions différentes, comme ce fut mon cas:
Nouveau référentiel cloné (Windows, Cygwin):
$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
Référentiel distant nu (Linux):
$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904 testfile
↑↑↑
J'ai eu le même problème. Aussi avec un Mac. En regardant le dépôt sur une machine Linux, j'ai remarqué que j'avais deux fichiers:
geoip.dat et GeoIP.dat
Supprimé le obsolète sur la machine Linux et cloné à nouveau le référentiel sur le mac. Je ne pouvais pas extraire, commettre, cacher ou extraire de ma copie du référentiel lorsqu'il y avait des doublons.
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 résoudre.
Ainsi, .gitattributes a un paramètre * text=auto qui est à l'origine de ce problème.
Dans mon cas, les fichiers sur la branche principale de GitHub avaient des fins \r\n. J'ai composé les paramètres du référentiel pour enregistrer avec les terminaisons \n. Je ne sais pas ce que git vérifie cependant. Il est supposé vérifier avec les terminaisons natives sur ma machine Linux (\n), mais je suppose qu’il a extrait le fichier avec les terminaisons \r\n. Git se plaint parce qu'il voit les terminaisons \r\n extraites qui étaient dans le dépôt et me prévient qu'il archivera les paramètres \n. Par conséquent, les fichiers doivent "être modifiés".
C'est ma compréhension pour l'instant.
Fichier d'édition appelé: Sudo gedit .git/configSudo vim .git/config
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
[remote "Origin"]
url = [email protected]: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
Changer filemode = true en filemode = false
Je viens aussi d'avoir le même problème. Dans mon cas, j'ai cloné le dépôt et certains fichiers ont immédiatement disparu.
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 aussi près que possible de la racine du disque dur afin de réduire la longueur du chemin d'accès au fichier, par exemple. clonez-le dans C:\A\GitRepo au lieu de C:\Utilisateurs Documents\aaa\Bureau\GitRepo
J'ai copié mon référentiel local dans un autre dossier et plusieurs fichiers modifiés sont apparus. Ma solution de contournement était: J'ai caché les fichiers modifiés et supprimé la cachette Le référentiel est devenu propre.
Juste au cas où cela aiderait quelqu'un d'autre, ce problème peut avoir une autre cause: des versions différentes 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 correctement, mais lors de la tentative de clonage du référentiel à l'aide de Git sous Ubuntu 16.04, certains fichiers étaient affichés comme modifiés.
Aucune des autres réponses ici n'a résolu mon problème, mais la mise à niveau des versions de Git afin qu'elles correspondent sur les deux systèmes a résolu le problème.
Même problème pour moi. Je pouvais voir plusieurs images portant le même nom, telles que "textField.png" et "textfield.png" dans le dépôt Git distant, mais pas sur mon dépôt local, je ne pouvais voir que "textField.png" qui n'était pas utilisé dans le project's code . Il s'avère que la plupart de mes collègues utilisent Ubuntu avec le système de fichiers ext4 alors que je suis sur un Mac utilisant APFS.
Grâce à la réponse de Sam Elliott , la solution était assez simple. J'ai d'abord demandé à un collègue sur Ubuntu de supprimer les versions de fichier redondantes avec la majuscule, puis de valider et d'envoyer à distance.
Puis j'ai couru 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 changer sa configuration Git pour éviter que cela ne se reproduise.
# Local Git config
git config core.ignorecase = true
ou
# Global Git config
git config --global core.ignorecase = true
J'ai trouvé que git traitait mes fichiers (.psd dans ce cas) en tant que texte. La définition d'un type binaire dans le fichier .gitattributes a résolu le problème.
*.psd binary
Pour les nouvelles versions de macOS, cela peut être dû à une fonctionnalité de sécurité du système d'exploitation.
Dans le référentiel sur lequel je travaillais, il y avait un fichier binaire contenant * .app comme type de fichier . Il ne s'agissait que de données sérialisées, mais macOS considère tous les fichiers * .app comme une application et, en tant que fichier non téléchargé par l'utilisateur, le système l'a jugé non sécurisé et a ajouté l'attribut de fichier com.Apple.quarantine qui garantit que le fichier ne peut pas être exécuté.
Mais définir cet attribut sur le fichier modifiait également le fichier et il apparaissait donc dans l'ensemble de modifications git sans aucun moyen de le restaurer.
Vous pouvez vérifier si vous avez 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'avais un problème similaire et j'ai trouvé cette question.
J'essayais de créer une base interactive, mais le logiciel prétendait qu'il y avait des fichiers modifiés, donc il ne me laissait pas le faire maintenant. J'ai tout essayé pour revenir à un dépôt 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! Clean repo. Problème résolu. Ensuite, j’ai dû abandonner le dernier commit lorsque j’ai fait mon rebase -i et finalement tout était à nouveau vierge . Bizarre!
Mais j'ajoute cette solution ici pour que peut-être que si je le revois, je le voie et l'essaie. Merci: D