L'application SourceTree indique des changements non engagés, même pour les dépôts nouvellement clonés - qu'est-ce qui pourrait ne pas aller?
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 tout de suite un tas de fichiers sous "modifications non engagées". Chaque dossier montre même nombre de lignes à la fois comme supprimé et ajouté, et ce nombre est égal au nombre total de lignes dans le fichier. Ça pourrait laisser penser qu'on a un problème de fin de ligne.
cependant, le dépôt .gitattribute contient
# Set default behaviour, in case users don't have core.autocrlf set.
* text=auto
que par article GitHub traitant des fins de ligne devrait rendre explicitement core.autocrlf vrai pour le dépôt. Toutefois aussi ~/.gitconfig contient autocrlf = true .
si les fichiers modifiés sont essayés de" revenir " à la propagation précédente, il n'y a aucun effet. Les mêmes fichiers sont toujours considérés comme non engagés.
le dépôt a été cloné dans plusieurs emplacements et s'est assuré qu'aucun fichier n'a été dans le même chemin, pour s'assurer que SourceTree ou git ne se souviennent pas des vieux fichiers.
le dépôt est collaboré avec Windows, Linux et les boîtes OSX. Ce problème n'apparaît que dans OSX.
Qu'est-ce qui pourrait encore ne pas aller dans la configuration SourceTree/repository/git?
mise à Jour #1, 20. Avril 2013
comme il y a toujours quelque chose qui ne va pas, voici des sorties partielles de git config --list .
From SourceTree console (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é de 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 complète .gitattributes pour le dépôt 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
5 réponses
je suis l'un des développeurs SourceTree (je développe la version Mac du produit, en fait), donc j'espère que je peux vous aider.
Les machines Windows convertissent CRLF en LF lors de l'engagement et LF en CRLF lors du départ. autocrlf s'assure que tout est LF dans le dépôt. L'option text = auto est celle qui nous intéresse bien que comme il dit dans le docs :
lorsque le texte est défini pour "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 en LF Sur checkin.
donc vous voyez sur checkin qu'il dira" Hé, j'ai besoin de normaliser ces terminaisons de ligne parce qu'elles ne sont pas en format LF, mais en CRLF."et modifie donc votre copie de travail pour faire le travail qu'il est censé faire. Généralement sur Mac / Linux vous n'avez pas besoin de normaliser parce que tout est en LF, mais Git faites une vérification parce que vous pourriez avoir vérifié à partir d'un dépôt 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 auriez probablement souhaitez re-valider l'ensemble de ces fichiers, car ils doivent être en LF format, mais assurez-vous également que autocrlf = true (édition, toujours pour vrai!) dans votre dépôt Windows comme il est indiqué dans les documents:
si vous voulez simplement avoir des fins de ligne CRLF dans votre répertoire de travail quel que soit le dépôt avec lequel vous travaillez, vous pouvez définir la variable de configuration "core.autocrlf " sans changer aucun attribut.
bien que imaginez que la citation précédente était en mettant autocrlf pour un dépôt spécifique aussi bien que globalement.
espérons que c'est d'une certaine aide, sinon, n'hésitez pas à poser plus de questions!
Voici une bonne façon à ce message re: ligne fin: Pourquoi devrais-je utiliser core.autocrlf=true dans Git?
modifier
Basé sur la réponse ci-dessus, nous avons besoin de quelques choses ici.
- que vous avez défini les options git pertinentes dans votre
.git/config - si vous voulez garder les fins de la ligne CRLF alors mettez
autocrlf=true - si, quand en vérifiant votre dépôt, vous ne voulez pas que vos fins de ligne soient converties automatiquement (ce qui fait que tous vos fichiers soient dans l'état "modifié" immédiatement), puis définissez l'option
textàunset. Ajoutez cette option si une configuration git globale l'a défini à une valeur que vous ne voulez pas. - si vous travaillez à la fois sur Windows et Mac pour un projet, alors il est préférable que vous avez
text=autoet assurez-vous que LF est utilisé dans tous les domaines. C'est pour cela que des problèmes comme celui-ci se glissent; parce que votre configuration de git diffère ou parce que la configuration initiale de project/git sur Windows suppose CRLF quand votre Mac assume LF.
Je ne le comprends toujours pas à 100%, mais pour nous le problème était le * text=auto dans le fichier .gitattribute dans le dépôt. J'ai vérifié, et nous avons pour sûr core.autocrlf=true mis dans chaque endroit où il peut être réglé pour mon utilisateur sur un PC Windows. Je savais que ce n'était pas un problème SourceTree non plus, car TortoiseGit et juste Windows Git (msysgit) avaient tous le même "problème" pour ce dépôt. Comportement vraiment bizarre - je clonerais la déclaration Une fois et immédiatement voir 11" différents " fichiers, puis je supprimerais et recommencer et le clone aurait 14 "différent" des fichiers.
commentant le * text=auto dans le fichier .gitattribute du dépôt a tout corrigé. Son 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 fichier .gitattribute . Mais ce n'est pas ce que tous les guides en ligne semblent indiquer.
vient de tomber dans ce numéro. Un clone frais tirerait plusieurs dossiers qui n'étaient pas seulement non engagés, mais avaient aussi beaucoup de lignes de vrai nouveau code. git reflog n'a rien montré, ce n'était pas un vrai commit donc une tête détachée était hors de question.
après une heure d'enquête, nous en avons trouvé la cause. Un de nos développeurs * nix avait, très probablement par erreur, ajouté des fichiers à un dossier qui portait le même nom que celui prévu mais avec des majuscules différentes. *nix les environnements ont été capables de gérer ce nouveau dossier facilement, mais Windows (en raison de sa nature insensible à la casse) a fusionné les deux dossiers.
donc, par exemple, si vous avez deux dossiers, test et Test, chacun avec un fichier.txt à l'intérieur et ces deux fichiers.les fichiers txt ne sont pas identiques, alors Windows va effectivement copier/remplacer l'un d'eux (pas sûr de l'ordre dans lequel il clone les dossiers) donc "changer" le fichier et la création de changements non engagés sur "Test/fichier.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 montrera toujours de nouvelles modifications non engagées consistant à ajouter les mots" avec quelques modifications " à Test/file.txt lors du clonage sur une machine Windows alors que les machines basées sur *nix n'auront pas de problème.
ceci n'aborde pas nécessairement la question de L'OP, mais se rapporte directement à la question dans le titre. J'espère que ça aide quelqu'un là-bas.
j'ai ajouté les deux lignes suivantes au fichier de configuration. L'autre chose que j'ai faite était de cliquer sur la case à cocher "fichiers mis en scène" et puis de la décoincer, et tout se rafraîchit. Bonne chance.
text = auto
autocrlf = true
normalement cette ligne dans .gitattribute :
* text=auto
garantit automatiquement que tous les fichiers que Git considère comme du texte auront des terminaisons de ligne normalisées (LF) dans le dépôt, même lorsque git config core.autocrlf est défini à false (par défaut). Git modifie donc automatiquement les fichiers selon ces règles.
donc vous avez les possibilités suivantes:
-
les modifications de normalisation sont correctes (dans la mesure où elles sont faites dans les fichiers texte) et il suffit de les propager, par exemple
$ git diff $ git commit -m "Introduce end-of-line normalization" -a -
supprimer/désactiver l'auto normalisation de la
.gitattributefichier et de réinitialiser les fichiers, -
supprimer l'index et re-scanner les fichiers, p.ex.
$ rm -v .git/index # Or: git rm --cached -r . $ git reset --hard # Rewrite the Git index. Or: git add -u -
alternativement, quoi que vous fassiez, essayez avec force (
,-f), p.ex.git pull origin -f,git checkout master -f, etc., - utiliser
gitligne de commande à la place, car il pourrait être un problème avec SourceTree App it-self.
Voir: Traiter avec des fins de ligne sur GitHub docs.