L’application SourceTree indique les modifications non validées, même pour un repository nouvellement cloné – qu’est-ce qui pourrait être faux?

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

Les machines Windows convertissent CRLF en LF lors de la validation et LF vers CRLF lors de la vérification. autocrlf s’assure que tout est dans le repository. L’option text = auto est celle qui nous intéresse, comme il est dit dans les docs :

Lorsque le texte est défini sur “auto”, le chemin est marqué pour une 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 à la fin, il va dire “Hey, je dois normaliser ces fins de ligne car elles ne sont pas au format LF, mais dans CRLF.” et modifie donc votre copie de travail pour faire le travail attendu. Habituellement, sous Mac / Linux, vous n’avez pas besoin de normaliser car tout est dans LF, mais Git effectuera une vérification car vous avez peut-être extrait un repository précédemment développé sous Windows, ou peut-être dans un éditeur utilisant CRLF. au lieu de LF.

Donc, en bref, vous voudrez probablement ré-engager tous ces fichiers comme ils devraient être au format LF, mais assurez-vous aussi que autocrlf = true (edit, toujours à true!) Dans votre repository Windows comme il est dit dans les docs :

Si vous voulez 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 atsortingbut.

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

J’espère que c’est d’une aide, sinon, n’hésitez pas à poser plus de questions!

Voici un bon post SO: fins de lignes: pourquoi devrais-je utiliser core.autocrlf = true dans Git?

MODIFIER

Sur la base de la réponse ci-dessus, nous devons nous assurer de quelques 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 la vérification de votre référentiel, vous ne souhaitez pas que vos fins de ligne soient automatiquement converties (entraînant la modification immédiate de tous vos fichiers), définissez l’option de text sur unset . Ajoutez cette option si une configuration globale de git l’a définie sur une valeur que vous ne voulez pas.
• Si vous travaillez à la fois sur Windows et Mac pour un projet, il est préférable que vous disposiez de text=auto et que vous vous assuriez que LF est utilisé à tous les niveaux. C’est pourquoi des problèmes comme celui-ci se manifestent; car votre configuration git est différente ou parce que la configuration initiale du projet / git sur Windows suppose CRLF lorsque votre Mac prend LF.

Je ne le comprends toujours pas à 100%, mais pour nous, le problème était le * text=auto dans le fichier .gitatsortingbute du référentiel. J’ai vérifié, et nous avons à coup sûr core.autocrlf=true défini partout où il peut être défini pour mon utilisateur sur un PC Windows. Je savais que ce n’était pas un problème de SourceTree non plus, car TortoiseGit et juste Windows Git (msysgit) avaient tous le même “problème” pour ce repository. Comportement vraiment étrange – je clonerais le repo une fois et je verrais immédiatement 11 fichiers “différents”, puis je supprimerais et recommencerais et le prochain clone aurait 14 fichiers “différents”.

Commenter le * text=auto dans le fichier .gitatsortingbute du référentiel 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 .gitatsortingbute . Mais ce n’est pas ce que chaque guide en ligne semble indiquer.

Juste couru dans ce problème. Un nouveau clone extrairait plusieurs fichiers non seulement non validés, mais aussi de nombreuses nouvelles lignes de code. git reflog n’a rien montré, ce n’était pas un engagement réel alors un HEAD détaché était hors de question.

Après environ une heure d’enquête, nous avons trouvé la cause. Un de nos développeurs * nix avait probablement ajouté par erreur des fichiers à un dossier portant le même nom que celui prévu, mais dont la capitalisation était 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 contenant un fichier.txt et ces deux fichiers.txt ne sont pas identiques, alors Windows en copiera / remplacera (pas certain de l’ordonner). clone les dossiers dans) modifiant ainsi le fichier et créant des modifications non validées 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 affichera toujours les nouvelles modifications non validées consistant à append les mots “avec quelques modifications” à Test / fichier.txt lors du clonage sur une machine Windows alors que les machines basées sur * nix n’auront pas de problème.

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

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 “Staged Files”, puis de la décocher, et tout s’est rafraîchi. Bonne chance.

 text = auto autocrlf = true 

Normalement, cette ligne dans .gitatsortingbute :

 * text=auto 

s’assure 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 si git config core.autocrlf est défini sur false (valeur par défaut). Par conséquent, Git modifie automatiquement les fichiers en fonction de ces règles.

Donc, vous avez les possibilités suivantes:

• supposons que les modifications de normalisation sont correctes (dans la mesure où elles sont effectuées dans les fichiers texte) et les commettent simplement, par exemple

   $ git diff $ git commit -m "Introduce end-of-line normalization" -a 

• supprimer / désactiver la normalisation automatique du fichier .gitatsortingbute et réinitialiser les fichiers,

• supprimer l’index et re-scanner les fichiers, par exemple

   $ 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 ), par exemple git pull origin -f , git checkout master -f , etc.,

• utilisez plutôt la ligne de commande git , car cela pourrait poser problème avec SourceTree App it-self.

Voir: Traitement des fins de ligne dans les documents GitHub.