Comment modifier les paramètres de fin de ligne


582

Existe-t-il un fichier ou un menu qui me permettra de modifier les paramètres de gestion des fins de ligne?

J'ai lu qu'il y a 3 options:

  1. Extraire le style Windows, valider le style Unix

    Git convertira LF en CRLF lors de l'extraction de fichiers texte. Lors de la validation des fichiers texte, CRLF sera converti en LF. Pour les projets multiplateformes, il s'agit du paramètre recommandé sous Windows ("core.autocrlf" est défini sur "true")

  2. Commander tel quel, valider le style Unix

    Git n'effectuera aucune conversion lors de l'extraction de fichiers texte. Lors de la validation des fichiers texte, CRLF sera converti en LF. Pour les projets multiplateformes, il s'agit du paramètre recommandé sous Unix ("core.autocrlf" est défini sur "input").

  3. Commander tel quel, valider tel quel

    Git n'effectuera aucune conversion lors de l'extraction ou de la validation de fichiers texte. Le choix de cette option n'est pas recommandé pour les projets multiplateformes ("core.autocrlf" est défini sur "false")



3
Laquelle de ces options est la valeur par défaut?
Stephen

2
Peu importe, il semble que la valeur par défaut soit vraie, ce qui, je pense, est approprié.
Stephen

19
En fait, je trouve que l'option 3-ème fonctionne mieux. Sinon, je me suis souvent retrouvé dans des situations où je modifiais les scripts batch et sh sur la même plate-forme (Windows / Linux), puis les validais et Git "corrigeait" automatiquement les fins de ligne pour une plate-forme ... Non, je préfère être auto- conscients des fins de ligne et les valider / vérifier exactement comme ils sont.
JustAMartin

1
@Neutrino J'aimerais que ce soit vrai, mais Visual Studio est un exemple d'IDE qui dérange avec vos fins de ligne (et n'offre pas d'option de configuration raisonnable pour désactiver cette option).
Cássio Renan

Réponses:


530

La façon normale de contrôler cela est avec git config

Par exemple

git config --global core.autocrlf true

Pour plus de détails, faites défiler vers le bas dans ce lien vers Pro Git jusqu'à la section nommée "core.autocrlf"


Si vous voulez savoir dans quel fichier il est enregistré, vous pouvez exécuter la commande:

git config --global --edit

et le fichier de configuration globale git devrait s'ouvrir dans un éditeur de texte, et vous pouvez voir d'où ce fichier a été chargé.


17
trueou falsene sont que deux options, le programme d'installation en a trois
qwertymk

49
inputest la 3ème option (comme indiqué dans le lien que j'ai fourni). Les 3 options sont true| false| input
CodingWithSpike

2
Voici une autre bonne question SO sur le sujet: stackoverflow.com/questions/3206843/…
CodingWithSpike

31
En fait, si vous relisez votre propre question, dans les extraits copiés / collés: "1 ... ("core.autocrlf" is set to "true") ... 2 ... ("core.autocrlf" is set to "input") ... 3 ... ("core.autocrlf" is set to "false")"vous avez donc essentiellement répondu à votre propre question? :)
CodingWithSpike

2
C'est l'ancienne façon de le contourner. Regardez le fichier .gitattributes.
eftshift0

176

Format de fin de ligne utilisé dans le système d'exploitation

  • Windows: paire CR(retour chariot \r) et LF(saut de ligne \n)
  • OSX, Linux: LF(LineFeed \n)

Nous pouvons configurer git pour corriger automatiquement les formats de fin de ligne pour chaque système d'exploitation de deux manières.

  1. Configuration globale de Git
  2. Utiliser un .gitattributesfichier

Configuration globale

Sous Linux / OSX
git config --global core.autocrlf input

Cela corrigera tout CRLFàLF lorsque vous vous engagez.

Sous Windows
git config --global core.autocrlf true

Cela garantira que lorsque vous passez à la caisse dans Windows, tout LFsera converti enCRLF

Fichier .gitattributes

C'est une bonne idée de conserver un .gitattributesfichier car nous ne voulons pas que tous les membres de notre équipe définissent leur configuration. Ce fichier doit rester dans le chemin racine du référentiel et s'il en existe un, git le respectera.

* text=auto

Cela traitera tous les fichiers comme des fichiers texte et les convertira en ligne de système d'exploitation se terminant à la caisse et de retour à la LFvalidation automatiquement. Si vous voulez le dire explicitement, utilisez

* text eol=crlf
* text eol=lf

Le premier est pour le paiement et le second pour la validation.

*.jpg binary

Traitez tout .jpg images comme des fichiers binaires, quel que soit le chemin. Aucune conversion n'est donc nécessaire.

Ou vous pouvez ajouter des qualificatifs de chemin:

my_path/**/*.jpg binary

3
Qu'en est-il d'OS X, qui utilise CR(retour chariot) seul?
jww

23
MacOS hérité (c'est-à-dire MacOS 9 et CRversions antérieures) utilisé seul, mais OS X utilise généralement LF.
Zachary Ware

2
Puis-je utiliser * text eol=lfdeux fois pour le commander avec LFWindows?
mbomb007

1
Selon gitattributes, le paramètre de documentation* text=auto permet à git de décider si le contenu est du texte ou non. Forcer tous les fichiers à être du texte ne devrait l'être * textque.
Adrian W

Comment définir eol=crdes fichiers sur Mac OS 9 et d'autres plates-formes héritées?
NobleUplift

36

Pour une solution de configuration de référentiel, qui peut être redistribuée à tous les développeurs, consultez l' attribut text dans le fichier .gitattributes . De cette façon, les développeurs n'ont pas à définir manuellement leurs propres fins de ligne sur le référentiel, et parce que différents référentiels peuvent avoir différents styles de fin de ligne, global core.autocrlf n'est pas le meilleur, du moins à mon avis.

Par exemple, la suppression de cet attribut sur un chemin donné [ .- texte] forcera git à ne pas toucher les fins de ligne lors de l'enregistrement et du retrait. À mon avis, c'est le meilleur comportement, car la plupart des éditeurs de texte modernes peuvent gérer les deux types de fins de ligne. De plus, si vous, en tant que développeur, souhaitez toujours effectuer une conversion de fin de ligne lors de l'archivage, vous pouvez toujours définir le chemin d'accès pour faire correspondre certains fichiers ou définir l'attribut eol (dans .gitattributes) sur votre référentiel.

Consultez également cet article connexe, qui décrit plus en détail le fichier .gitattributes et l'attribut texte: Quelle est la meilleure stratégie de gestion CRLF (retour chariot, saut de ligne) avec Git?


. - textdonne is not a valid attribute name: .gitattributes:1s'il vous plaît mettrecat .gitattributes
jangorecki

3

Pour moi, qu'est-ce que l'astuce a été d'exécuter la commande

git config auto.crlf false

à l'intérieur du dossier du projet, je le voulais spécifiquement pour un projet.

Cette commande a changé le fichier dans le chemin {nom_projet} /. Git / config (fyi .git est un dossier caché) en ajoutant les lignes

[auto]
    crlf = false

à la fin du fichier. Je suppose que changer le fichier fait aussi la même chose.


1

Si vous souhaitez reconvertir les formats de fichiers qui ont été modifiés au format UNIX à partir du format PC.

(1) Vous devez réinstaller tortoise GIT et dans la section "Conversion de fin de ligne", assurez-vous d'avoir sélectionné l'option "Extraire tel quel - Enregistrer tel quel".

(2) et conservez les configurations restantes telles quelles.

(3) une fois l'installation terminée

(4) écrire toutes les extensions de fichier converties au format UNIX dans un fichier texte (extensions.txt).

ex:*.dsp
   *.dsw

(5) copiez le fichier dans votre clone Exécutez la commande suivante dans GITBASH

while read -r a;
do
find . -type f -name "$a" -exec dos2unix {} \;
done<extension.txt
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.