Comment de fin de ligne des conversions de travailler avec git-core.autocrlf entre les différents systèmes d'exploitation

J'ai lu beaucoup de différentes questions et réponses sur le Débordement de la Pile ainsi que git de la documentation sur la façon dont le de base.autocrlf paramètre fonctionne.

C'est ma compréhension de ce que j'ai lu:

Unix et Mac OSX (pré-OSX utilise CR) les clients utilisent LF fins de ligne.

Les clients Windows utiliser CRLF les fins de ligne.

Quand le noyau.autocrlf est définie sur true, le client, le dépôt git stocke toujours les fichiers dans la FL de fin de ligne format et les fins de ligne dans les fichiers sur le client sont convertis en arrière et en avant sur départ /de s'engager pour les clients (c'est à dire Windows) que l'utilisation non-LF fins de ligne, quel que soit le format de fins de ligne fichiers sont sur le client (ce n'est pas d'accord avec Tim Clem définition - voir la mise à jour ci-dessous).

Ici est une matrice qui tente de document de la même façon pour le "entrée" et "faux" paramètres de base.autocrlf avec des points d'interrogation là où je ne suis pas sûr de fin de ligne de conversion de comportement.

Mes questions sont:

  1. Quelle devrait être la question de la marque?
  2. Est cette matrice correct pour le "non de points d'interrogation"?

Je vais mettre à jour les points d'interrogation à partir des réponses que le consensus semble être formée.

 de base.autocrlf valeur 
vrai faux entrée 
---------------------------------------------------------- 
s'engager | convertir ? ? 
nouveau | à la FL (convertir à la FL?) (pas de conversion?) 

s'engager | convertir ? pas de 
existant | LF (convertir à la FL?) conversion 

checkout | convertir ? pas de 
existant | CRLF (pas de conversion?) conversion

Je ne suis pas vraiment à la recherche d'avis sur les avantages et les inconvénients des différents paramètres. Je suis juste à la recherche de données qui met en lumière le fait de s'attendre à git pour fonctionner avec chacun des trois paramètres.

--

Mise à jour 04/17/2012: Après la lecture de l'article de Tim Clem lié par JJD dans les commentaires, j'ai modifié certaines des valeurs de "l'inconnu" les valeurs dans le tableau ci-dessus, ainsi que l'évolution des "checkout actuel | vrai pour convertir à CRLF au lieu de les convertir en clients". Voici les définitions qu'il donne, et qui sont de plus en plus clair que tout ce que j'ai vu ailleurs:

de base.autocrlf = false

C'est la valeur par défaut, mais la plupart des gens sont encouragés à modifier cette
immédiatement. Le résultat de l'utilisation de faux, c'est que Git n'a pas toujours mess
avec des fins de ligne dans votre fichier. Vous pouvez vérifier dans les fichiers avec LF ou CRLF
ou CR ou certaines mélange aléatoire de ces trois-là et Git ne se soucie pas. Cette
peut rendre les comparaisons plus difficiles à lire et fusionne en plus difficile. La plupart des gens
travailler dans un monde Unix/Linux utiliser cette valeur parce qu'ils n'ont pas
CRLF problèmes et ils n'ont pas besoin de Git pour faire du travail supplémentaire à chaque fois que
les fichiers sont écrits à l'objet de base de données ou par écrit dans le
répertoire de travail.

de base.autocrlf = true

Cela signifie que Git va traiter tous les fichiers texte et assurez-vous que
CRLF est remplacé par LF lors de l'écriture de ce fichier dans la base de données d'objets
et tourner tous les LF de retour dans CRLF lors de l'écriture dans le travail
répertoire. C'est le réglage recommandé sur Windows parce que c'
veille à ce que votre espace de stockage peut être utilisé sur d'autres plateformes
en conservant CRLF dans votre répertoire de travail.

de base.autocrlf = entrée

Cela signifie que Git va traiter tous les fichiers texte et assurez-vous que
CRLF est remplacé par LF lors de l'écriture de ce fichier à l'objet
la base de données. Il ne sera pas, cependant, faire l'inverse. Lorsque vous lisez des fichiers
de retour de l'objet de base de données et de les écrire dans le travail
répertoire qu'ils ont encore de l'Epa pour désigner la fin de la ligne. Cette
paramètre est généralement utilisé sur les systèmes Unix/Linux/OS X afin d'empêcher CRLFs de
être écrite dans le référentiel. L'idée étant que si vous avez collé
code à partir d'un navigateur web et accidentellement obtenu CRLFs dans l'un de vos
fichiers, Git assurez-vous qu'ils ont été remplacés par de l'Epa quand vous avez écrit
à l'objet de base de données.

Tim article est excellent, la seule chose à laquelle je pense qui manque, c'est qu'il suppose que le référentiel est en LF format, ce qui n'est pas nécessairement vrai, surtout pour Windows uniquement des projets.

Comparant Tim est l'article le plus voté de réponse à ce jour par jmlane montre parfait accord sur le vrai et les paramètres d'entrée et de désaccord sur le paramètre false.

  • En gardant autocrlf false semble donc plus facile 😉 stackoverflow.com/questions/2333424/...
  • J'ai lu cela et je pense que je le comprends, mais je n'ai pas nécessairement de faire le choix. Je travaille avec des dépôts git que je ne contrôle pas, qui nécessitent de définir la valeur d'une certaine manière.
  • et, en fonction sur le serveur Git version, les règles sur la fin de vie et autocrlf sont sur le point de changer dans les prochaines 1.7.2! Voir article.gmane.org/gmane.linux.kernel/1007412
  • Ne serait-il pas agréable si Windows normalisée à LF trop? Le Mac utilisé pour être CR (avant v10), mais est maintenant normalisée à LF.
  • J'ai besoin d'ajouter un lien vers l'excellent article de Timothy Clem - merci de lire l'Esprit à la Fin de Votre Ligne.
  • Scénario: je suis un split Linux/Windows développeur. Je n'utilise que des éditeurs de texte qui permet de reconnaître les deux types de fins de ligne (IE. vim, eclipse). J'ai seulement besoin (envie) de travailler avec les fichiers se terminant par LF. J'ai actuellement de base.autocrlf=jeu de données d'entrée dans mon global git config. Suis-je bien aller? J'aurai jamais un conflit?
  • que le lien de l'article est maintenant mort, mais je suppose que la viande c'est dans la réponse ci-dessus, mais peut-être un lien permanent pourrait être trouvé?
  • Le Internet Archive passe autrefois stockés version de l'article de Timothy Clem.

InformationsquelleAutor Michael Maddox | 2010-07-08
  1. 117

    La meilleure explication de la façon dont core.autocrlf œuvres se trouve sur la gitattributes page de man, dans la text section attribut.

    C'est de cette façon core.autocrlf semble fonctionner actuellement (ou au moins depuis v1.7.2 à partir de ce que je suis au courant):

    • core.autocrlf = true
      1. Fichiers texte extrait du référentiel qui ont seulement LF personnages sont normalisées pour CRLF dans votre arbre de travail; les fichiers qui contiennent CRLF dans le dépôt ne sera pas touché
      2. Des fichiers texte qui ont seulement LF caractères dans le référentiel, sont normalisées à partir de CRLF à LF lorsqu'il est commis vers le dépôt. Les fichiers qui contiennent CRLF dans le référentiel sera engagé intacte.
    • core.autocrlf = input
      1. Fichiers texte extrait du référentiel permettra de garder l'original EOL caractères dans votre arbre de travail.
      2. Fichiers texte dans votre arbre de travail avec CRLF personnages sont normalisées pour LF lorsqu'il est commis vers le dépôt.
    • core.autocrlf = false
      1. core.eol dicte EOL caractères dans les fichiers texte de votre arbre de travail.
      2. core.eol = native par défaut, ce qui signifie que Windows EOLs sont CRLF et *nix EOLs sont LF de travail dans les arbres.
      3. Référentiel gitattributes paramètres détermine le caractère de fin de ligne de la normalisation pour les livraisons dans le dépôt (la valeur par défaut est la normalisation de LF caractères).

    J'ai tout récemment des recherches sur cette question et je trouve aussi que la situation est très compliquée. Le core.eol réglage certainement contribué à clarifier la façon dont EOL caractères sont traités par git.

    • pour autocrlf=true ne devrait pas être le suivant? Des fichiers texte qui ont seulement CRLF EOL caractères dans le référentiel, sont normalisées à partir de CRLF à la FL lorsqu'il est commis vers le dépôt. Les fichiers qui contiennent LF dans le référentiel sera engagé intacte.
    • Pour moi, même si autocrlf=false git a été la conversion de l'EOL à CRLF. Après la lecture de cette réponse, j'ai réalisé que mon .gitattribute fichier texte=auto set qui a été à l'origine du problème.
    • Pour core.autocrlf = false, si je n'ai pas de gitattributes fichier veut-il dire qu'il n'y aura pas de normalisation? Ou faut-il dire qu'il va utiliser la valeur par défaut de normalisation?
    InformationsquelleAutor jmlane
  2. 56

    La question de la EOLs dans les projets de la plateforme a été prise de ma vie misérable pour un long moment. Les problèmes surviennent généralement quand il y a déjà des fichiers avec différents et mixtes EOLs déjà dans le repo. Cela signifie que:

    1. Le repo peut avoir différents fichiers avec différents EOLs
    2. Certains fichiers dans le repo peut avoir mélangé EOL, par exemple, une combinaison de CRLF et LF dans le même fichier.

    Comment cela se passe n'est pas la question ici, mais ça arrive.

    J'ai couru quelques tests de conversion sur Windows pour les différents modes et de leurs combinaisons.

    Voici ce que j'ai, quelque peu modifiée de la table:

     | Résultant de la conversion quand Découlant de la conversion quand 
| valider des fichiers avec divers | vérification DE repo - 
| EOLs EN pensions de titres et | avec un mélange de fichiers et 
| core.autocrlf valeur: | core.autocrlf valeur: 
-------------------------------------------------------------------------------- 
Fichier | vrai | entrée | faux | vrai | input | faux 
-------------------------------------------------------------------------------- 
Windows-cr /lf | cr /lf -> LF | cr /lf -> LF | comme | comme | comme | comme-est 
Unix -LF | comme | comme | comme | LF -> CRLF | comme | comme-est 
Mac -CR | comme | comme | comme | comme | comme | comme-est 
Mixte CRLF+LF | comme | comme | comme | comme | comme | comme-est 
Mixte CRLF+LF+CR | comme | comme | comme | comme | comme | comme-est

    Comme vous pouvez le voir, il y a 2 cas lorsque la conversion se produit lors de la validation (3 colonnes de gauche). Dans le reste des cas, les fichiers sont engagés en tant que-est.

    Au moment de l'extraction (3 colonnes), il ya seulement 1 cas où la conversion se produit lorsque:

    1. core.autocrlf est true et
    2. le fichier dans le repo a la LF EOL.

    Le plus surprenant pour moi, et je soupçonne que la cause de nombreux EOL problèmes, c'est qu'il n'y a pas de configuration dans lequel mixte EOL comme CRLF+LF obtenir normalisé.

    Note également que les "vieux" Mac EOLs de CR seulement jamais convertis.

    Cela signifie que si un mal écrit conversion EOL script essaie de convertir un mixte de fin de fichier avec CRLFs+LFs, juste par la conversion de LFs à CRLFs, alors il va laisser le fichier en mode mixte avec "lonely" CRs où un CRLF a été converti à CRCRLF.

    Git ne sera pas convertir quoi que ce soit, même dans true mode, et en fin de vie des ravages continue. Cette réalité m'est arrivé et foiré mes fichiers vraiment mal, car certains éditeurs et les compilateurs (par exemple VS2010) n'aime pas les Mac EOLs.

    Je suppose que la seule façon de vraiment gérer ces problèmes est d' parfois normaliser l'ensemble des pensions de par la vérification de tous les fichiers dans input ou false mode, l'exécution d'un bon de normalisation et de ré-engager les fichiers modifiés (le cas échéant). Sur Windows, sans doute reprendre le travail avec core.autocrlf true.

    • Excellente réponse, mais une phrase avec laquelle je ne peux pas d'accord, c'est Sur Windows, sans doute reprendre le travail avec core.autocrlf true. Personnellement, je crois que input doit être toujours utilisée.
    InformationsquelleAutor Adi Shavit
  3. 38

    Les choses sont sur le point de changer la "conversion eol" avant, avec la venir Git 1.7.2:

    Un nouveau paramètre de configuration de base.eol est en cours d'ajout/a évolué:

    C'est un remplacement pour le " Ajouter "core.eol" variable de config' s'engager dans pu (le dernier de ma série).

    Au lieu de dire que "core.autocrlf=true" est un remplacement pour "* text=auto", il rend explicite le fait que autocrlf est seulement pour les utilisateurs qui veulent travailler avec
    CRLFs dans leur répertoire de travail sur un référentiel qui n'a pas de texte
    fichier de normalisation    .

    Lorsqu'elle est activée, "noyau.eol" est ignoré.

    Introduire une nouvelle variable de configuration, "core.eol", qui permet à l'utilisateur de définir les fins de ligne à utiliser pour une fin-de-ligne-normalisé des fichiers dans le répertoire de travail.

    La valeur par défaut est "native", ce qui signifie CRLF sur Windows et LF partout ailleurs.
    Notez que "core.autocrlf" remplace core.eol.

    Cela signifie que:

    [core]
  autocrlf = true

    met CRLFs dans le répertoire de travail, même si core.eol est réglé sur "lf".

    core.eol:

    Définit le type de fin de ligne à utiliser dans le répertoire de travail pour les fichiers qui ont le text ensemble de propriétés.

    Les solutions de rechange sont 'lf', 'crlf" et "indigènes", qui utilise la plate-forme du natif de fin de ligne.

    La valeur par défaut est native.

    D'autres évolutions sont considérés comme:

    Pour la 1.8, je voudrais envisager de faire core.autocrlf il suffit de tourner sur la normalisation et de laisser le répertoire de travail de fin de ligne de la décision de base.eol, mais que sera pause du peuple configurations.

    git 2.8 (Mars 2016) améliore la façon dont core.autocrlf influences de l'eol:

    Voir s'engager 817a0c7 (23 Février 2016), s'engager 6e336a5, s'engager df747b8, s'engager df747b8 (10 Février 2016), s'engager df747b8, s'engager df747b8 (10 Février 2016), et s'engager 4b4024f, s'engager bb211b4, s'engager 92cce13, s'engager 320d39c, s'engager 4b4024f, s'engager bb211b4, s'engager 92cce13, s'engager 320d39c (05 Février 2016) par Torsten Bögershausen (tboegi).

    (Fusionnés par Junio C Hamano -- gitster -- dans s'engager c6b94eb, 26 Février 2016)

    convert.c: refactoriser crlf_action

    Refactoriser la détermination et l'utilisation de crlf_action.

    Aujourd'hui, lorsqu'il n' "crlf" attribut sont définis dans un fichier, crlf_action est fixé à
    CRLF_GUESS. Utilisation CRLF_UNDEFINED au lieu de cela, et de la recherche pour "text" ou "eol" comme avant.

    Remplacer l'ancien CRLF_GUESS utilisation:

    CRLF_GUESS && core.autocrlf=true -> CRLF_AUTO_CRLF
CRLF_GUESS && core.autocrlf=false -> CRLF_BINARY
CRLF_GUESS && core.autocrlf=input -> CRLF_AUTO_INPUT

    Faire plus clair, qu'est-ce que, par définition:

    - CRLF_UNDEFINED : No attributes set. Temparally used, until core.autocrlf
                   and core.eol is evaluated and one of CRLF_BINARY,
                   CRLF_AUTO_INPUT or CRLF_AUTO_CRLF is selected
- CRLF_BINARY    : No processing of line endings.
- CRLF_TEXT      : attribute "text" is set, line endings are processed.
- CRLF_TEXT_INPUT: attribute "input" or "eol=lf" is set. This implies text.
- CRLF_TEXT_CRLF : attribute "eol=crlf" is set. This implies text.
- CRLF_AUTO      : attribute "auto" is set.
- CRLF_AUTO_INPUT: core.autocrlf=input (no attributes)
- CRLF_AUTO_CRLF : core.autocrlf=true  (no attributes)

    Comme torek ajoute dans les commentaires:

    toutes ces traductions (aucune conversion EOL de eol= ou autocrlf paramètres, et "clean" filtres) sont exécutées lorsque les fichiers déplacer d'arbre en arbre d'index, c'est à dire, au cours de git add plutôt qu'à git commit temps.

    (Notez que git commit -a ou --only ou --include faire ajouter des fichiers à l'index, à l'époque, cependant).

    Pour en savoir plus, voir "Quelle est la différence entre autocrlf et eol".

    • Cela, malheureusement, ne pas ajouter de la clarté pour moi. Il semble qu'ils sont en train de dire qu'il ya des problèmes avec l'implémentation actuelle (il n'est pas clair ce que sont ces problèmes) et qu'ils sont l'accroissement de la complexité dans un effort pour résoudre ces quelconques problèmes. À mon avis, à la base.autocrlf est déjà trop complexe et sous-documentées et que la situation semble empirer. Encore merci pour le heads up.
    • Ce ne semble pas être une solution satisfaisante, et semble avoir les mêmes problèmes que ceux de base.autocrlf. Ma préférence serait si git ne serait jamais automatiquement modifier quoi que ce soit, mais il serait avertir l'utilisateur qui veut ajouter ou de commettre le mal des fins de ligne. Si vous avez besoin d'une option de ligne de commande pour permettre de "git add" pour ajouter le "mal" les fins de ligne. (probablement git add est le meilleur endroit pour vérifier ce que git commit)
    • Ce serait forcer l'utilisateur à modifier leurs paramètres de l'éditeur et de vraiment prendre soin de ce problème. Alors qu'il permettrait de quitter la "mauvaise" fin de ligne, pour les fichiers à partir du 3 parties, ou qui sont déjà enregistrés dans le référentiel.
    • encore une fois, je suis d'accord. Mais core.eol est sur "modifier automatiquement" seulement ce que vous avez explicitement déclarer dans un .gitattributes fichier. Ceci est différent de la core.autocrlf qui s'applique à aucun fichier dans le repo. C'est un processus déclaratif.
    • ah, ok. Donc, si je Comprends bien, si .gitattributes est vide, core.autocrlf assumera certaines de fichier par défaut des types de toujours convertir, alors que de base.eol assumera rien. Mais une fois que vous créez une .gitattributes, puis à la fois le noyau.eol et de base.autocrlf va se comporter de la même manière?
    • Et oui vous êtes d'accord, mais je voulais quand même le dire ici, car il semble plus pertinent de dire que dans d'autres question.
    • Je me rends compte c'est assez vieux mais je n'en ai lu votre commentaire maintenant. En fait, toutes ces traductions (aucune conversion EOL de eol= ou autocrlf paramètres, et "nettoyer" les filtres) sont exécutées lorsque les fichiers déplacer d'arbre en arbre d'index, c'est à dire, au cours de git add plutôt qu'à git commit temps. (Notez que git commit -a ou --only ou --include faire ajouter des fichiers à l'index, à l'époque, cependant). Pour ce que ça vaut, vous et moi, et Linus Torvalds tous les déteste l'idée d'un VCS jamais modification de ce qui est engagé. Mais il y a tous ces utilisateurs de Windows... 🙂
    • Merci pour le commentaire. Je l'ai incluse dans la réponse pour plus de visibilité.
    • C'est un grand poste. Merci à tous pour les dans la profondeur des éclaircissements. Cependant, j'ai une question qui reste encore sans réponse (au moins pour moi). J'ai envie de faire appliquer autocrlf=entrée par le biais de la gitattributes fichier, comment puis-je le faire?
    • Vous avez besoin d'une base.eol directive, associé à '*' (pour tous les fichiers) Voir git-scm.com/docs/gitattributes#gitattributes-Settostringvaluelf: eol=lf si vous êtes sur Linux.
    • si ma compréhension est correcte, core.eol implique que tous les fichiers associés à ce filtre ses fins de ligne converti à lf dans mon répertoire de travail. Je n'en veux pas. Ce que je veux, c'est à la caisse as is et de s'engager avec lf qui est ce core.autocrlf=input si ma compréhension est correcte à nouveau.
    • Je suis d'accord. Cela signifie que le noyau.eol peut-être pas le bon outil.
    • ce qui nous ramène à ma question initiale. Est-il un moyen de faire respecter core.autocrlf=input de l'intérieur de la .gitattributes dans le but de propager la politique au fil de mes collègues ?
    • Bonne question; peut-on demander comme un organisme indépendant, puisque je ne suis pas sûr de la réponse en fonction de ce qui est indiqué ci-dessus?
    • Merci pour les réponses immédiates. J'ai juste fait un post indépendant question ici: stackoverflow.com/questions/42667996/...

    InformationsquelleAutor VonC
  4. 27

    core.autocrlf valeur ne dépend pas du type de système d'exploitation, mais sur Windows par défaut la valeur est true et pour Linux - input. J'ai exploré de 3 valeurs possibles pour la validation et la caisse des cas, et c'est la table résultante:

    ╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => LF   ║
║ git commit    ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => CRLF ║
║ git checkout  ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝
    • J'aime la lisibilité de ce tableau. +1
    • Shorty résumé en mots: les Fichiers avec CR seul ne sont jamais touchés. false ne touche jamais les fins de ligne. true toujours s'engage comme LF et vérifie que CRLF. Et input toujours s'engage comme LF et vérifie que-est.
    InformationsquelleAutor pratt
  5. 6

    Voici ma compréhension de celui-ci jusqu'à présent, dans le cas où il aide quelqu'un.

    core.autocrlf=true et core.safecrlf = true

    Vous avez un référentiel où toutes les fins de ligne sont les mêmes, mais vous travaillez sur différentes plates-formes. Git va assurez-vous que vos lignes de terminaisons sont convertis à la valeur par défaut pour votre plate-forme. Pourquoi est-ce important? Imaginons que vous créez un nouveau fichier. L'éditeur de texte sur votre plate-forme sera utiliser par défaut les fins de ligne. Lorsque vous l'enregistrez, si vous n'avez pas de cœur.autocrlf définie sur true, vous avez introduit une ligne de fin de l'incohérence pour quelqu'un sur une plate-forme, qui est par défaut à un autre de fin de ligne. J'ai toujours mis safecrlf trop parce que je voudrais savoir ce que le crlf opération est réversible. Avec ces deux paramètres, git est en train de modifier 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à mélangé les fins de ligne vérifié et à la fixation de la ligne incorrecte terminaisons casser d'autres choses. De son mieux pour ne pas dire à git pour convertir les fins de ligne dans ce cas, car alors il ne fera qu'exacerber le problème, il a été conçu pour résoudre les décisions des diffs plus facile à lire et fusionne moins douloureux. Avec ce paramètre, git ne modifie pas vos fichiers.

    core.autocrlf=input

    Je ne pas l'utiliser, parce que la raison pour cela est de couvrir un cas d'utilisation où vous avez créé un fichier qui a CRLF les fins de ligne sur une plate-forme, qui est par défaut à la FL fins de ligne. Je préfère plutôt que de faire de mon éditeur de texte toujours d'enregistrer de nouveaux fichiers avec la plate-forme de fin de ligne par défaut.

    InformationsquelleAutor Carl
  6. 2

    Fait quelques tests à la fois sur linux et windows. J'utilise un fichier de test contenant des lignes se terminant en LF et aussi des lignes se terminant par CRLF.

    Fichier est engagé , enlevé puis vérifié.
    La valeur de base.autocrlf est défini avant de s'engager et aussi avant de valider votre commande.
    Le résultat est ci-dessous.

    commit core.autocrlf false, remove, checkout core.autocrlf false: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf input: LF=>LF   CRLF=>CRLF  
commit core.autocrlf false, remove, checkout core.autocrlf true : LF=>LF   CRLF=>CRLF  
commit core.autocrlf input, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf input, remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF  
commit core.autocrlf true, remove, checkout core.autocrlf false: LF=>LF   CRLF=>LF  
commit core.autocrlf true, remove, checkout core.autocrlf input: LF=>LF   CRLF=>LF  
commit core.autocrlf true,  remove, checkout core.autocrlf true : LF=>CRLF CRLF=>CRLF
    InformationsquelleAutor Luc Depoorter
  7. 1

    Non, l' @jmlane réponse est fausse.

    Pour Checkin (git add, git commit):

    1. si text propriété est Set, Set value to 'auto', la conversion se produit frfr le fichier a été commis avec "CRLF'
    2. si text propriété est Unset:rien ne se passe, frfr pour Checkout
    3. si text propriété est Unspecified, conversion dépend core.autocrlf
      1. si autocrlf = input or autocrlf = true, la conversion ne se produit que lorsque le fichier dans le référentiel est "LF", si elle a été "CRLF', rien ne se passe.
      2. si autocrlf = false, rien ne se passe

    Pour Checkout:

    1. si text propriété est Unset: rien ne se passe.
    2. si text propriété est Set, Set value to 'auto: il dépend de core.autocrlf, core.eol.
      1. de base.autocrlf = input : rien ne se passe
      2. de base.autocrlf = true : la conversion ne se produit que lorsque le fichier dans le référentiel est 'LF', 'LF' -> "CRLF'
      3. de base.autocrlf = false : la conversion ne se produit que lorsque le fichier dans le référentiel est 'LF', 'LF' -> core.eol
    3. si text propriété est Unspecified, il dépend de core.autocrlf.
      1. le même que 2.1
      2. le même que 2.2
      3. Aucun, rien ne se passe, core.eol n'est pas efficace lorsque text propriété est Unspecified

    Comportement par défaut

    De sorte que le comportement par Défaut est text propriété est Unspecified et core.autocrlf = false:

    1. pour l'enregistrement, rien ne se passe
    2. pour la caisse, il ne se passe rien

    Conclusions

    1. si text propriété est définie, checkin comportement dépend d'elle-même, pas sur autocrlf
    2. autocrlf ou de base.eol est pour la caisse de comportement, et autocrlf > core.eol
    InformationsquelleAutor ViciOs