39 votes

l'état de git montre des modifications même avec autocrlf = false

Je suis en train de vivre les mêmes problèmes que dans cette question: git status affiche des modifications, git checkout -- <fichier> ne pas les supprimer

Git continue d'afficher le répertoire de travail les modifications, même avec git config --global core.autocrlf false:

E:\_dev\github\Core [master +0 ~93 -0]> git config --get-all core.autocrlf
false
false

(Notez que j'ai même mis l' --system définition false)

Pourquoi est-ce que Git est encore la modification de ma fin de lignes?

Les tentatives de se débarrasser de modifications

Référence

E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

git checkout -- .

E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed) 
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

Occasionnellement, cela aura un effet dans une drôle de façon:

E:\_dev\github\Core [master +0 ~628 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~361 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .

git reset --hard

E:\_dev\github\Core [master +0 ~93 -0]> git reset --hard
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master
E:\_dev\github\Core [master +0 ~93 -0]>

git add .; git stash; git stash drop

E:\_dev\github\Core [master +0 ~93 -0]> git add .
... warnings ....
warning: CRLF will be replaced by LF in tools/StatLight/StatLight.EULA.txt.
The file will have its original line endings in your working directory.

E:\_dev\github\Core [master +0 ~93 -0]> git stash
Saved working directory and index state WIP on master: 11a7f9a Merge pull request #8 from 
RemiBou/master
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master

E:\_dev\github\Core [master +0 ~93 -0]> git stash drop
Dropped refs/stash@{0} (de4c3c863dbad789aeaf563b4826b3aa41bf11b7)

E:\_dev\github\Core [master +0 ~93 -0]> git status .\tools\StatLight\StatLight.EULA.txt
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

23voto

Brecht Machiels Points 408

Cela semble être un bug dans msysgit. Pour contourner ce problème, essayez de créer un fichier .gitattributes contenant

 * -text
 

Cela indiquera à git de ne pas effectuer de conversions EOL sur aucun fichier.

10voto

VonC Points 414372

Vérifiez si vous n'avez pas d' .gitattributes le fichier

Comme mentionné dans la section"Effet" de la gitattributes page de man, ces fichiers peuvent également avoir un effet sur la fin de vie et la transformation automatique:

text ^^^^^^

Cet attribut permet à et les contrôles de fin de ligne de la normalisation.
Lorsqu'un fichier texte normalisé, ses fins de ligne sont convertis LF dans le référentiel.
Pour contrôler ce style de fin de ligne est utilisé dans le répertoire de travail, l'utilisation de l'eol attribut d'un fichier unique et l' core.eol variable de configuration pour tous les fichiers texte.

Vérifiez également votre config pour core.eol, comme indiqué dans "Comment de fin de ligne des conversions de travailler avec git core.autocrlf entre différents systèmes d'exploitation".

7voto

nexbit Points 56

Je suis enquêter sur l'étrange comportement de base.autocrlf dans MSysGit, et j'ai trouvé que le fait d'avoir:

[core]
    autocrlf = false
    safecrlf = true
    ignorecase = true
    eol = native 

dans le global fichier de config et PAS de cœur.autocrlf paramètre dans une pension de copié à partir d'un autre PC (pas cloné, seulement copié), l'émission d'un git status résultats de la commande dans TOUS les fichiers de texte marqué comme modifié (pas de gitattributes autour).

Mais si vous ajoutez un local (référentiel) de base.autocrlf paramètre à true, et alors l' git status de la commande, toutes les modifications disparaît et le référentiel tourne le dos à être propre.

MAIS (et c'est le comportement étrange) si vous enlevez la juste ajouté de base.autocrlf paramètre à partir du référentiel de fichier de config (donc de revenir exactement à l'état initial), la commande git status continue de rapport pas de changements!

Étant donné qu'aucune opération n'a été effectuée sur le dépôt, seulement la modification d'un paramètre de configuration, et de revenir à l'état d'origine, a fait le tour...

Si ce n'est pas un bug, je ne peux pas imaginer qui dans le monde peut appeler cela un comportement "normal".

5voto

marioatlp Points 301

Ce problème peut être causé par gitattributes' option de texte.

Veuillez lire attentivement la documentation, mais essentiellement, autocrlf seulement des questions si text n'est pas situé dans une .gitattributes:

Non spécifié
Si le texte de l'attribut n'est pas spécifié, la commande git utilise la base.autocrlf variable de configuration pour déterminer si le fichier doit être converti.

Trouvez votre .gitattributes le fichier via:

find <root-dir> -name .gitattributes

Et grep pour text, eol ou crlf pour trouver votre coupable et réviser, au besoin.

Vous pouvez changer ce fichier et revenir à l', mais sans s'engager pour une période suffisamment longue pour obtenir par le biais de votre question.

1voto

131 Points 645

question de « autocrlf » est un problème typique de repo cross plateforme multi (ie en utilisant une part de samba avec TortoiseGit sur un serveur sous linux)

J'ai réalisé que parfois (souvent), c'est plus un problème de "chmod" qu'un autocrlf: - les fenêtres d'état git affichent les modifications en attente - git status linux n'affiche rien

"changement de mode 100755 => 100644 config / packager.xml"

Vérifiez que vos fichiers "statiques" ne sont pas + x, (et dans ce cas tortoisegit ne l'aimera pas)

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X