Git 1.6.4 beta sur Windows (msysgit) - Terminaison de ligne Unix ou DOS

Question

Je suis en train d'installer msysgit 1.6.4 beta sur mon VPC de développement Windows Vista. Un écran d'installation me demande si je veux utiliser la terminaison de ligne Unix ou la terminaison de ligne DOS. D'ordinaire, je choisirais DOS, mais le texte d'installation indique que la terminaison DOS peut signifier que les fichiers ne fonctionnent pas avec tous les outils de ligne de commande de Git. La terminaison de ligne Unix indique "...la plupart des applications [Windows] peuvent gérer cela...".

Quelqu'un sait-il quelle option je devrais choisir pour utiliser Git via le shell pour mon travail sur VS 2008 ?

Answer 1

Ce paramétrage lors de l'installation de msysgit est en fait là pour fixer la valeur de l'attribut core.autocrlf config .

core.autocrlf

Si vrai, fait convertir par git CRLF à la fin des lignes dans les fichiers texte pour LF lors de la lecture à partir du système de fichiers, et la conversion inverse lors de l'écriture dans le système de fichiers.

La variable peut être définie comme ' input Dans ce cas, la conversion n'a lieu que lors de la lecture du système de fichiers, mais les fichiers sont écrits avec l'option LF à la fin des lignes.

Actuellement, les chemins à considérer comme "texte" (c'est-à-dire à soumettre au mécanisme autocrlf) sont décidés uniquement en fonction de leur contenu.

J'insiste sur no essayer de convertir quoi que ce soit automatiquement, les effets secondaires sont tout simplement trop importants (en termes de conflit de fusion potentiel, en particulier dans le cadre d'un développement distribué avec différents environnements).

Si vos outils peuvent gérer la terminaison de ligne de type Unix, vous devriez les configurer pour produire des lignes Unix, qui peuvent alors être lues par Windows (VS2008, Notepad++, ...) et Unix, et peuvent être traitées par n'importe quel script 'sh' Git-scripts.

Mais avec core.autocrlf à false, la décision de transformer la fin d'une ligne de texte sera une décision explicite volontaire, et non un effet de bord invisible en arrière-plan.

---

Voir plus sur " Comment les conversions de fin de ligne fonctionnent-elles avec git core.autocrlf entre différents systèmes d'exploitation "

                 | Resulting conversion when       | Resulting conversion when 
                 | committing files with various   | checking out FROM repo - 
                 | EOLs INTO repo and              | with mixed files in it and
                 |  core.autocrlf value:           | core.autocrlf value:           
--------------------------------------------------------------------------------
File             | true       | input      | false | true       | input | false
--------------------------------------------------------------------------------
Windows-CRLF     | CRLF -> LF | CRLF -> LF | as-is | as-is      | as-is | as-is
Unix -LF         | as-is      | as-is      | as-is | LF -> CRLF | as-is | as-is
Mac  -CR         | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF    | as-is      | as-is      | as-is | as-is      | as-is | as-is
Mixed-CRLF+LF+CR | as-is      | as-is      | as-is | as-is      | as-is | as-is

Answer 2

Poignées de Visual Studio 2008 Unix sans problème. Toutefois, il essaiera de détecter les fichiers texte dont les fins de ligne sont incohérentes afin de les corriger. Le Bloc-notes, quant à lui, n'est pas en mesure d'afficher correctement les caractères Unix les fichiers texte.

Answer 3

J'ai trouvé un comparaison sur stackoverflow qui explique ce qui se passe avec les fichiers lors des actions de validation et de contrôle.