L'application SourceTree indique des modifications non validées même pour le référentiel nouvellement cloné - qu'est-ce qui pourrait ne pas être le cas?

Question

Un dépôt git distant vient d'être cloné dans une boîte locale en utilisant Atlassian SourceTree . Même si aucun fichier n'a vraiment été modifié dans l'arborescence de travail, Atlassian répertorie immédiatement un tas de fichiers sous "Modifications non validées". Chaque fichier affiche le même nombre de lignes supprimées et ajoutées, et ce nombre est égal au nombre total de lignes dans le fichier. Cela donnerait en quelque sorte un indice que nous rencontrons une sorte de problème de fin de ligne.

Cependant, le référentiel .gitattribute contient

# Set default behaviour, in case users don't have core.autocrlf set. * text=auto

que par article GitHub Gérer les fins de ligne devrait faire explicitement core.autocrlf true pour le référentiel. Mais aussi ~/.gitconfig contient autocrlf = true.

Si les fichiers modifiés sont tentés d'être "rétablis" à la validation précédente, il n'y a aucun effet. Les mêmes fichiers sont toujours considérés comme non validés.

Le référentiel a été cloné dans plusieurs emplacements et s'est assuré qu'aucun fichier ne se trouvait dans le même chemin, pour s'assurer que SourceTree ou git ne se souviennent pas des anciens fichiers.

Le référentiel est collaboré avec les boîtiers Windows, Linux et OSX. Ce problème apparaît uniquement dans OSX.

Qu'est-ce qui pourrait encore être mal dans la configuration de SourceTree/repository/git?

Mise à jour # 1, 20 avril 2013

Comme il y a encore quelque chose qui ne va pas, voici les sorties partielles de git config --list.

Depuis la console SourceTree (OSX)

core.excludesfile=/Users/User/.gitignore_global core.autocrlf=input difftool.sourcetree.cmd=opendiff "$LOCAL" "$REMOTE" difftool.sourcetree.path= mergetool.sourcetree.cmd=/Applications/SourceTree.app/Contents/Resources/opendiff-w.sh "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$MERGED" mergetool.sourcetree.trustexitcode=true core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true core.autocrlf=true

Voici la sortie correspondante du côté Windows:

core.symlinks=false core.autocrlf=false color.diff=auto color.status=auto color.branch=auto color.interactive=true pack.packsizelimit=2g help.format=html http.sslcainfo=/bin/curl-ca-bundle.crt sendemail.smtpserver=/bin/msmtp.exe diff.astextplain.textconv=astextplain rebase.autosquash=true http.proxy= core.autocrlf=true core.repositoryformatversion=0 core.filemode=false core.bare=false core.logallrefupdates=true core.symlinks=false core.ignorecase=true core.hidedotfiles=dotGitOnly core.eol=native core.autocrlf=true

Et plein .gitattributes pour le référentiel en question

# Set default behaviour, in case users don't have core.autocrlf set. * text=auto *.php text *.twig text *.js text *.html text diff=html *.css text *.xml text *.txt text *.sh text eol=lf console text *.png binary *.jpg binary *.gif binary *.ico binary *.xslx binary

Kezzer · Accepted Answer

Je suis l'un des développeurs de SourceTree (je développe la version Mac du produit, en fait), donc j'espère pouvoir vous aider.

Les machines Windows convertissent CRLF en LF lors de la validation et LF en CRLF lors de l'extraction. autocrlf s'assure que tout est LF dans le référentiel. L'option text = auto est celui qui nous intéresse, car il dit dans la documentation :

Lorsque le texte est défini sur "auto", le chemin est marqué pour la normalisation automatique de fin de ligne. Si git décide que le contenu est du texte, ses fins de ligne sont normalisées à LF lors de l'archivage.

Donc, vous voyez à l'enregistrement, il dira "Hé, j'ai besoin de normaliser ces fins de ligne car elles ne sont pas au format LF, mais au format CRLF.") Et modifie ainsi votre copie de travail à faire généralement sur Mac/Linux, vous n'avez pas besoin de normaliser car tout est en LF, mais Git fera une vérification parce que vous avez peut-être extrait d'un référentiel qui a été précédemment développé sur Windows, ou peut-être dans un éditeur qui utilisait CRLF au lieu de LF.

Donc, en bref, vous voudrez probablement recréer tous ces fichiers tels qu'ils devraient être au format LF, mais assurez-vous également que autocrlf = true (modifier, toujours vrai!) dans votre référentiel Windows comme il est dit dans les documents:

Si vous souhaitez simplement avoir des fins de ligne CRLF dans votre répertoire de travail, quel que soit le référentiel avec lequel vous travaillez, vous pouvez définir la variable de configuration "core.autocrlf" sans modifier aucun attribut.

Bien imaginez que la citation précédente était lors de la configuration de autocrlf pour un référentiel spécifique ainsi que globalement.

J'espère que cela vous sera utile, sinon, n'hésitez pas à poser plus de questions!

Voici un bon SO post re: line endings: Pourquoi devrais-je utiliser core.autocrlf = true dans Git?

[~ # ~] modifier [~ # ~]

Sur la base de la réponse ci-dessus, nous devons nous assurer de certaines choses ici.

Que vous avez défini les options git pertinentes dans votre .git/config
Si vous souhaitez conserver les fins de ligne CRLF, définissez autocrlf=true
Si, lors de l'extraction de votre référentiel, vous ne voulez pas que vos fins de ligne soient automatiquement converties (ce qui fait que tous vos fichiers sont immédiatement "modifiés"), définissez l'option text sur unset. Ajoutez cette option si une configuration globale git la définit sur une valeur que vous ne souhaitez pas.
Si vous travaillez à la fois sur Windows et sur Mac pour un projet, il est préférable que vous ayez text=auto et assurez-vous que LF est utilisé dans tous les domaines. C'est pourquoi des problèmes comme celui-ci se glissent; parce que votre configuration git diffère ou parce que la configuration initiale du projet/git sur Windows suppose CRLF lorsque votre Mac suppose LF.

Adam Nofsinger · Answer

Je ne le comprends toujours pas à 100%, mais pour nous, le problème était le * text=auto dans le .gitattribute fichier dans le référentiel. J'ai vérifié, et nous avons certainement core.autocrlf=true défini à chaque endroit, il peut être défini pour mon utilisateur sur un PC Windows. Je savais que ce n'était pas non plus un problème avec SourceTree, car TortoiseGit et juste Windows Git (msysgit) avaient tous le même "problème" pour ce référentiel. Comportement vraiment étrange - je clonerais le dépôt une fois et verrais immédiatement 11 fichiers "différents", puis je supprimerais et recommencerais et le clone suivant aurait 14 fichiers "différents".

Commentant le * text=auto dans le .gitattribute le fichier du référentiel a tout corrigé. C'est presque comme text=auto ne se comporte pas comme autocrlf=true et ce dernier est désactivé si le premier est défini dans le .gitattribute fichier. Mais ce n'est pas ce que tout guide en ligne semble indiquer.

vr_driver · Answer

J'ai ajouté les deux lignes suivantes au fichier de configuration. L'autre chose que j'ai faite a été de cliquer sur la case à cocher "Fichiers intermédiaires", puis de la décocher, et tout s'est actualisé. Bonne chance.

text = auto autocrlf = true

kenorb · Answer

Normalement, cette ligne dans .gitattribute:

* text=auto

garantit automatiquement que tous les fichiers que Git considère comme du texte auront des fins de ligne normalisées (LF) dans le référentiel, même lorsque git config core.autocrlf est défini sur false (par défaut). Par conséquent, Git modifie automatiquement les fichiers selon ces règles.

Vous avez donc les possibilités suivantes:

supposez que les changements de normalisation sont corrects (dans la mesure où ils sont effectués dans les fichiers texte) et validez-les simplement, par exemple.
```
$ git diff $ git commit -m "Introduce end-of-line normalization" -a 
```
supprimer/désactiver la normalisation automatique du .gitattribute fichier et réinitialiser les fichiers,

supprimer l'index et ré-analyser les fichiers, par exemple.

$ rm -v .git/index # Or: git rm --cached -r . $ git reset --hard # Rewrite the Git index. Or: git add -u

sinon, quoi que vous fassiez, essayez avec force (-f), par exemple. git pull Origin -f, git checkout master -f, etc.,
utilisez plutôt la ligne de commande git, car cela pourrait être un problème avec SourceTree App lui-même.

Voir: Gérer les fins de ligne sur les documents GitHub.

Colt McCormack · Answer

Je suis juste tombé sur ce problème. Un nouveau clone tirerait plusieurs fichiers qui n'étaient pas seulement non validés, mais qui comportaient également de nombreuses lignes de vrai nouveau code. git reflog ne montrait rien, ce n'était pas un commit réel donc un détaché HEAD était hors de question.

Après environ une heure d'enquête, nous avons trouvé la cause. L'un de nos développeurs * nix avait, très probablement par erreur, ajouté des fichiers à un dossier portant le même nom que celui prévu mais avec une capitalisation différente. * Les environnements nix ont pu gérer ce nouveau dossier facilement, mais Windows (en raison de sa nature insensible à la casse) a fusionné les deux dossiers.

Ainsi, par exemple, si vous avez deux dossiers, test et Test, chacun avec un fichier.txt à l'intérieur et que ces deux fichiers file.txt ne sont pas identiques, alors Windows copiera/remplacera l'un d'eux (pas sûr de l'ordre clone les dossiers dans) "changeant" ainsi le fichier et créant des modifications non validées sur "Test/file.txt" directement après une nouvelle installation.

Exemple:

test/ --file.txt (with contents of "This is a commit") Test/ --file.txt (with contents of "This is a commit with some changes")

Cela affichera toujours de nouvelles modifications non validées consistant à ajouter les mots "avec quelques modifications" à Test/file.txt lors du clonage sur une machine Windows tandis que les machines basées sur * nix n'auront pas de problème.

Cela ne résout pas nécessairement le problème du PO, mais se rapporte directement à la question dans le titre. J'espère que cela aide quelqu'un là-bas.