J'ai lu de nombreuses questions et réponses sur Stack Overflow ainsi que de la documentation git sur le fonctionnement du paramètre core.autocrlf .
Voici ma compréhension de ce que j'ai lu:
Les clients Unix et Mac OSX (pré-OSX utilise CR) utilisent les terminaisons de ligne LF.
Les clients Windows utilisent des fins de ligne CRLF.
Lorsque core.autocrlf est défini sur true sur le client, le référentiel git stocke toujours les fichiers au format de fin de ligne LF et les fins de ligne dans les fichiers sur le client sont converties dans les deux sens lors de l'extraction / validation pour les clients (c'est-à-dire Windows) qui utilisent non -LF fin de ligne, quel que soit le format des fichiers de fin de ligne sur le client (cela n'est pas conforme à la définition de Tim Clem - voir la mise à jour ci-dessous).
Voici une matrice qui essaie de documenter la même chose pour les paramètres 'input' et 'false' de core.autocrlf avec des points d'interrogation où je ne suis pas sûr du comportement de conversion de fin de ligne.
Mes questions sont:
- Quels devraient être les points d'interrogation?
- Cette matrice est-elle correcte pour les "non-points d'interrogation"?
Je mettrai à jour les points d'interrogation des réponses car un consensus semble se former.
valeur core.autocrlf vrai entrée faux -------------------------------------------------- -------- commettre | convertir? ? nouveau | en LF (convertir en LF?) (pas de conversion?) commettre | convertir en ? non existant | Conversion LF (convertir en LF?) caisse | convertir en ? non existant | Conversion CRLF (pas de conversion?)
Je ne suis pas vraiment à la recherche d'opinions sur les avantages et les inconvénients des différents paramètres. Je cherche juste des données qui indiquent clairement comment attendre que git fonctionne avec chacun des trois paramètres.
-
Mise à jour 17/04/2012 : Après avoir lu l'article de Tim Clem lié par JJD dans les commentaires, j'ai modifié certaines des valeurs dans les valeurs "inconnues" dans le tableau ci-dessus, ainsi que changé "checkout existant | true pour convertir" en CRLF au lieu de convertir en client ". Voici les définitions qu'il donne, qui sont plus claires que tout ce que j'ai vu ailleurs:
core.autocrlf = false
C'est la valeur par défaut, mais la plupart des gens sont encouragés à changer cela immédiatement. Le résultat de l'utilisation de false est que Git ne dérange jamais les fins de ligne de votre fichier. Vous pouvez archiver des fichiers avec LF ou CRLF ou CR ou un mélange aléatoire de ces trois et Git s'en fiche. Cela peut rendre les différences plus difficiles à lire et les fusionner plus difficiles. La plupart des gens travaillant dans un monde Unix / Linux utilisent cette valeur car ils n'ont pas de problèmes CRLF et ils n'ont pas besoin que Git fasse un travail supplémentaire chaque fois que des fichiers sont écrits dans la base de données d'objets ou écrits dans le répertoire de travail.
core.autocrlf = true
Cela signifie que Git traitera tous les fichiers texte et s'assurera que CRLF est remplacé par LF lors de l'écriture de ce fichier dans la base de données d'objets et remettra tous les LF en CRLF lors de l'écriture dans le répertoire de travail. Il s'agit du paramètre recommandé sous Windows car il garantit que votre référentiel peut être utilisé sur d'autres plates-formes tout en conservant CRLF dans votre répertoire de travail.
core.autocrlf = entrée
Cela signifie que Git traitera tous les fichiers texte et s'assurera que CRLF est remplacé par LF lors de l'écriture de ce fichier dans la base de données d'objets. Il ne fera cependant pas l'inverse. Lorsque vous lisez des fichiers de la base de données d'objets et les écrivez dans le répertoire de travail, ils auront toujours des LF pour indiquer la fin de la ligne. Ce paramètre est généralement utilisé sur Unix / Linux / OS X pour empêcher les CRLF d'être écrits dans le référentiel. L'idée étant que si vous colliez du code à partir d'un navigateur Web et introduisiez accidentellement des CRLF dans l'un de vos fichiers, Git s'assurait qu'ils étaient remplacés par des LF lorsque vous écriviez dans la base de données d'objets.
L'article de Tim est excellent, la seule chose à laquelle je pense qu'il manque, c'est qu'il suppose que le référentiel est au format LF, ce qui n'est pas nécessairement vrai, en particulier pour les projets Windows uniquement.
La comparaison de l'article de Tim avec la réponse la plus votée à ce jour par jmlane montre un accord parfait sur les paramètres true et input et un désaccord sur le paramètre false.
la source
autocrlf
à faux semble tellement plus facile;) stackoverflow.com/questions/2333424/…Réponses:
La meilleure explication du
core.autocrlf
fonctionnement se trouve sur la page de manuel gitattributes , dans latext
section attribut.Voici comment
core.autocrlf
semble fonctionner actuellement (ou du moins depuis la v1.7.2 d'après ce que je sais):core.autocrlf = true
LF
caractères sont normalisésCRLF
dans votre arborescence de travail; les fichiers qui contiennentCRLF
dans le référentiel ne seront pas touchésLF
caractères dans le référentiel sont normalisés deCRLF
àLF
lorsqu'ils sont validés dans le référentiel. Les fichiers qui contiennentCRLF
dans le référentiel seront validés intacts.core.autocrlf = input
CRLF
caractères sont normalisésLF
lorsqu'ils sont renvoyés dans le référentiel.core.autocrlf = false
core.eol
dicte les caractères EOL dans les fichiers texte de votre arborescence de travail.core.eol = native
par défaut, ce qui signifie que les EOL Windows sontCRLF
et que les EOL * nix sontLF
dans des arborescences de travail.gitattributes
paramètres du référentiel déterminent la normalisation des caractères EOL pour les validations dans le référentiel (la normalisation par défaut est lesLF
caractères).Je viens tout juste de faire des recherches sur cette question et je trouve également que la situation est très compliquée. Le
core.eol
paramètre a certainement aidé à clarifier la façon dont les caractères EOL sont gérés par git.la source
core.autocrlf = false
, si je n'ai pas degitattributes
fichier, cela signifie-t-il qu'il n'y aura pas de normalisation? Ou cela signifie-t-il qu'il utilisera la normalisation par défaut?.gitattributes
fichier ne doit-il pas prévaloir sur lacore.autocrlf
configuration?La question des EOL dans les projets multi-plateformes rend ma vie misérable depuis longtemps. Les problèmes surviennent généralement lorsqu'il existe déjà des fichiers avec des EOL différents et mixtes déjà dans le référentiel . Cela signifie que:
CRLF
etLF
dans le même fichier.Comment cela se produit n'est pas le problème ici, mais cela se produit.
J'ai effectué des tests de conversion sur Windows pour les différents modes et leurs combinaisons.
Voici ce que j'ai obtenu, dans un tableau légèrement modifié:
Comme vous pouvez le voir, il y a 2 cas où la conversion se produit lors de la validation (3 colonnes de gauche). Dans les autres cas, les fichiers sont validés tels quels.
Lors du paiement (3 colonnes de droite), il n'y a qu'un seul cas où la conversion se produit lorsque:
core.autocrlf
esttrue
etLF
.Le plus surprenant pour moi, et je soupçonne, la cause de nombreux problèmes d'EOL est qu'il n'y a pas de configuration dans laquelle les EOL mixtes comme
CRLF
+LF
sont normalisés.Notez également que les "anciens" EOL Mac
CR
ne sont également jamais convertis.Cela signifie que si un script de conversion EOL mal écrit essaie de convertir un fichier de fin mixte avec
CRLF
s +LF
s, en convertissant simplementLF
s enCRLF
s, il laissera le fichier en mode mixte avec "solitaire"CR
partout où a aCRLF
été convertiCRCRLF
.Git ne convertira alors rien, même en
true
mode, et les ravages d'EOL se poursuivent. Cela m'est réellement arrivé et a vraiment gâché mes fichiers, car certains éditeurs et compilateurs (par exemple VS2010) n'aiment pas les EOL Mac.Je suppose que la seule façon de vraiment gérer ces problèmes est de normaliser de temps en temps l'ensemble du référentiel en vérifiant tous les fichiers en mode
input
oufalse
, en exécutant une normalisation appropriée et en réinitialisant les fichiers modifiés (le cas échéant). Sur Windows, reprenez probablement le travail aveccore.autocrlf true
.la source
core.autocrlf true
. Je crois personnellement que celainput
devrait toujours être utilisé.Les choses sont sur le point de changer du côté de la "conversion eol", avec le prochain Git 1.7.2 :
Un nouveau paramètre de configuration
core.eol
est ajouté / évolué :D'autres évolutions sont à l'étude :
git 2.8 (mars 2016) améliore la façon dont
core.autocrlf
influence le eol:Voir commettre 817a0c7 (23 février 2016), engager 6e336a5 , engager df747b8 , engager df747b8 (10 février 2016), engager df747b8 , engager df747b8 (10 février 2016), et engager 4b4024f , engager bb211b4 , engager 92cce13 , engager 320d39c , engager 4b4024f , commit bb211b4 , commit 92cce13 , commit 320d39c (05 février 2016) par Torsten Bögershausen (
tboegi
) .(Fusionné par Junio C Hamano -
gitster
- en commit c6b94eb, 26 févr.2016)Comme l'a ajouté torek dans les commentaires :
Pour plus d'informations, voir " Quelle est la différence entre autocrlf et eol ".
la source
core.eol
s'agit de "modifier automatiquement" uniquement ce que vous déclarez explicitement dans un.gitattributes
fichier. Ceci est différent de celuicore.autocrlf
qui s'applique à n'importe quel fichier du référentiel. Il s'agit d'un processus déclaratif.git add
plutôt qu'à l'git commit
heure. (Notez quegit commit -a
ou--only
ou--include
faire des fichiers add à l'index à ce moment - là, cependant.) Pour ce que ça vaut la peine, vous et moi , et Linus Torvalds tout déteste l'idée d'un VCS jamais modifier ce qui est commis. Mais il y a tous ces utilisateurs de Windows ... :-)core.autocrlf
la valeur ne dépend pas du type de système d'exploitation mais de la valeur par défaut de Windows esttrue
et pour Linux -input
. J'ai exploré 3 valeurs possibles pour les cas de validation et d'extraction et voici le tableau résultant:la source
CR
seuls ne sont jamais touchés.false
ne touche jamais les fins de ligne.true
valide toujours en tant queLF
et vérifie en tant queCRLF
. Etinput
s'engage toujours tel quelLF
et vérifie tel quel.Voici ma compréhension jusqu'à présent, au cas où cela aiderait quelqu'un.
core.autocrlf=true
etcore.safecrlf = true
Vous avez un référentiel où toutes les fins de ligne sont les mêmes , mais vous travaillez sur différentes plateformes. Git s'assurera que les terminaisons de vos lignes sont converties à la valeur par défaut pour votre plate-forme. Pourquoi est-ce important? Disons que vous créez un nouveau fichier. L'éditeur de texte sur votre plateforme utilisera ses fins de ligne par défaut. Lorsque vous l'archivez, si core.autocrlf n'est pas défini sur true, vous avez introduit une incohérence de fin de ligne pour quelqu'un sur une plate-forme qui prend par défaut une fin de ligne différente. Je mets toujours safecrlf aussi parce que je voudrais savoir que l'opération crlf est réversible. Avec ces deux paramètres, git modifie vos fichiers, mais il vérifie que les modifications sont réversibles .
core.autocrlf=false
Vous avez un référentiel qui a déjà des fins de ligne mixtes archivées et la correction des fins de ligne incorrectes pourrait casser d'autres choses. Il est préférable de ne pas dire à git de convertir les fins de ligne dans ce cas, car cela aggravera le problème qu'il a été conçu pour résoudre - rendant les différences plus faciles à lire et fusionnant moins douloureuses. Avec ce paramètre, git ne modifie pas vos fichiers .
core.autocrlf=input
Je ne l'utilise pas parce que la raison en est de couvrir un cas d'utilisation où vous avez créé un fichier qui a des fins de ligne CRLF sur une plate-forme qui par défaut est des fins de ligne LF. Je préfère plutôt que mon éditeur de texte enregistre toujours les nouveaux fichiers avec les valeurs par défaut de fin de ligne de la plate-forme.
la source
Non, la réponse @jmlane est fausse.
Pour
Checkin (git add, git commit)
:text
propriété estSet, Set value to 'auto'
, la conversion se produit enen le fichier a été validé avec 'CRLF'text
propriété estUnset
: rien ne se passe, enen pourCheckout
text
propriété estUnspecified
, la conversion dépend decore.autocrlf
autocrlf = input or autocrlf = true
, la conversion ne se produit que lorsque le fichier dans le référentiel est «LF», s'il a été «CRLF», rien ne se passera.autocrlf = false
rien ne se passePour
Checkout
:text
propriété estUnset
: rien ne se passe.text
propriété estSet, Set value to 'auto
: cela dépendcore.autocrlf
,core.eol
.core.eol
text
propriété estUnspecified
, cela dépendcore.autocrlf
.2.1
2.2
text
propriété estUnspecified
Comportement par défaut
Ainsi, le comportement par défaut est la
text
propriété estUnspecified
etcore.autocrlf = false
:Conclusions
text
propriété est définie, le comportement d'archivage dépend de lui-même, pas de autocrlfla source
A fait quelques tests sur Linux et Windows. J'utilise un fichier de test contenant des lignes se terminant par LF et également des lignes se terminant par CRLF.
Le fichier est validé, supprimé puis extrait. La valeur de core.autocrlf est définie avant la validation et également avant le retrait. Le résultat est ci-dessous.
la source