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

Question

J'ai lu beaucoup de questions et de réponses différentes sur Stack Overflow ainsi que sur git la documentation sur la façon dont le core.autocrlf les travaux d'aménagement.

C'est ce que je comprends d'après ce que j'ai lu :

Les clients Unix et Mac OSX (les clients pré-OSX utilisent CR) utilisent des fins de ligne LF.
Les clients Windows utilisent des fins de ligne CRLF.

Lorsque core.autocrlf est défini à true sur le client, le dépôt git stocke toujours les fichiers au format de terminaison de ligne LF et les terminaisons de ligne dans les fichiers sur le client sont converties dans les deux sens lors du check out / commit pour les clients (c'est-à-dire Windows) qui utilisent des terminaisons de ligne non-LF, quel que soit le format des fichiers de terminaisons de ligne sur le client (ceci est en désaccord avec la définition de Tim Clem - voir la mise à jour ci-dessous).

Voici une matrice qui tente de documenter la même chose pour les paramètres 'input' et 'false' de core.autocrlf avec des points d'interrogation lorsque je ne suis pas sûr du comportement de conversion des fins de lignes.

Mes questions sont les suivantes :

1. Que doivent être les points d'interrogation ?
2. Cette matrice est-elle correcte pour les "points de non-question" ?

Je mettrai à jour les points d'interrogation des réponses au fur et à mesure qu'un consensus semble se former.

                       core.autocrlf value
            true            input              false
----------------------------------------------------------
commit   |  convert           ?                  ?
new      |  to LF      (convert to LF?)   (no conversion?)

commit   |  convert to        ?                 no 
existing |  LF         (convert to LF?)     conversion

checkout |  convert to        ?                 no
existing |  CRLF       (no conversion?)     conversion

Je ne cherche pas vraiment à obtenir des avis sur les avantages et les inconvénients des différents réglages. Je cherche simplement des données qui permettent de comprendre comment git doit fonctionner avec chacun de ces trois paramètres.

--

Mise à jour du 17 avril 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 le changement de "checkout existing | 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

Il s'agit de la valeur par défaut, mais la plupart des gens sont encouragés à la modifier. immédiatement. Le résultat de l'utilisation de false est que Git ne s'embarrasse jamais avec 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 éléments et Git ne s'en soucie pas. Ce Cela peut rendre les diffs plus difficiles à lire et les merges plus difficiles. La plupart des personnes La plupart des personnes travaillant dans le monde Unix/Linux utilisent cette valeur parce qu'elles problèmes de CRLF et n'ont pas besoin que Git fasse du travail supplémentaire à chaque fois que des fichiers sont écrits dans la base de données des objets ou dans le répertoire de travail.

core.autocrlf = true

Cela signifie que Git traitera tous les fichiers textes et s'assurera que les CRLF est remplacé par LF lors de l'écriture de ce fichier dans la base de données objet et transformera tous les LF en CRLF lors de l'écriture dans le répertoire de travail de travail. C'est la configuration recommandée sous Windows car elle garantit que votre référentiel peut être utilisé sur d'autres plates-formes tout en 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 les fichiers CRLF soit remplacé par LF lors de l'écriture de ce fichier dans la base de données d'objets. En revanche, il ne fera pas l'inverse. Lorsque vous lisez des fichiers de la base de données des objets et que vous les écrivez dans le répertoire de travail ils auront toujours des LF pour indiquer la fin de la ligne. Ceci Ce paramètre est généralement utilisé sur Unix/Linux/OS X pour empêcher les CRLFs d'être d'être écrits dans le référentiel. L'idée étant que si vous collez code depuis un navigateur web et que vous avez accidentellement mis des CRLFs dans un de vos fichiers, Git s'assurerait qu'ils soient remplacés par des LF lorsque vous écrivez dans la base de données objet.

L'article de Tim est excellent, la seule chose qui me semble manquer est qu'il suppose que le référentiel est au format LF, ce qui n'est pas forcément vrai, surtout pour les projets uniquement Windows.

En comparant l'article de Tim à celui qui a été le plus voté réponse à ce jour par jmlane montre un accord parfait sur les paramètres vrai et entrée et un désaccord sur le paramètre faux.

Answer 1

Non, la réponse de @jmlane est fausse.

For Checkin (git add, git commit) :

1. si text la propriété est Set, Set value to 'auto' la conversion se fait lorsque le fichier a été validé avec 'CRLF'.
2. si text la propriété est Unset :rien ne se passe, enen pour Checkout
3. si text la propriété est Unspecified la conversion dépend de core.autocrlf
   1. si autocrlf = input or autocrlf = true la conversion ne se fait que lorsque le fichier dans le dépôt est 'LF', s'il a été 'CRLF', rien ne se passe.
   2. si autocrlf = false rien ne se passe

For Checkout :

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

Comportement par défaut

Le comportement par défaut est donc text la propriété est Unspecified y core.autocrlf = false :

1. pour le checkin, rien ne se passe
2. pour la caisse, rien ne se passe

Conclusions

1. si text est définie, le comportement du checkin dépend de lui-même, pas d'autocrlf.
2. autocrlf ou core.eol est pour le comportement de la caisse, et autocrlf > core.eol

Answer 2

J'ai fait quelques tests sous linux et Windows. J'utilise un fichier de test contenant des lignes se terminant par LF et aussi des lignes se terminant par CRLF.
Le fichier est validé, supprimé et ensuite extrait. La valeur de core.autocrlf est définie avant le commit et aussi avant le checkout. Le résultat est le suivant.

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

Answer 3

La déclaration core.autocrlf=true conduisant à CRLF -> LF sur l'engagement est tout faux ! Ce n'est pas si simple, comme vous allez le voir...

El docs dire que le réglage correspond à... " text=auto en .gitattributes y core.eol étant réglé sur crlf dans la configuration git" ...ce qui signifie quoi exactement ?

Ce qui signifie que, si un fichier n'a pas de .gitattributes texte et si l'attribut core.autocrlf es true Dans ce cas, oui, il sera normalisé en LF dans la base de données git repo), ou s'il s'agit d'un fichier existant que vous avez édité et que vous êtes en train de livrer (dans ce cas, RIEN ne se passera... à moins que vous n'exécutiez la commande git add --renormalize . dans ce cas, il sera normalisé dans la base de données git repo).

Vous voyez... tout le mécanisme ne se produit que pour un fichier pour lequel une .gitattributes a no a placé une variante de l'attribut text : text , -text , text=auto .

Donc, ce que vous devriez vraiment chercher à faire, c'est utiliser .gitattributes avec un paramètre par défaut sur tous vos fichiers, soit :

* -text
# followed by specialization

qui donnera par défaut à tous les éléments (sauf les spécialisations) la valeur suivante en l'état et de remplacer core.autocrlf complètement, ou en utilisant une valeur par défaut de :

*  text=auto
# followed by specialization

ce qui signifie que tous les fichiers (à l'exception des spécialisations) que git détecte automatiquement comme non binaires (texte), et qui ont LF dans la base de données git [voir note 1.] , obtiendra CRLF à chaque fois :
    - core.autocrlf es true ou
    - core.eol es crlf ou
    - core.eol es native (par défaut) et que vous êtes sur une plateforme Windows.
Dans tous les autres cas, vous obtenez LF .

De quelles spécialisations s'agit-il ? Par exemple, avoir .bat Les fichiers sont CRLF y .sh Les fichiers sont LF via soit :

*.sh           text eol=lf

# *.bat
*.[bB][aA][tT] text eol=crlf

ou

# *.sh are committed correctly as-is (LF)
*.sh           -text

# *.bat are committed correctly as-is (CRLF)
*.[bB][aA][tT] -text

Alors oui... tout n'est pas si simple.

---

[note 1] :
Ce sera le cas pour tous les fichiers correspondant à l'option text=auto (c'est-à-dire qu'il n'a pas d'autre spécialisation), puisque je suppose que votre dépôt a été correctement normalisé lorsque l'attribut .gitattribute a été créé