Les retours chariot et les sauts de ligne finiront par vous mordre - Quelques astuces Git

Qu'est-ce qu'un chariot et pourquoi revient-il ? Retour chariot Saut de ligne QU'EST-CE QUE CELA SIGNIFIE ?

Le papier sur une machine à écrire roule horizontalement sur un chariot. Le retour chariot ou CR était un caractère de contrôle non imprimable qui réinitialisait la machine à écrire au début de la ligne de texte.

Cependant, un retour chariot fait reculer le chariot mais n'avance pas le papier d'une ligne. Le chariot se déplace sur les axes X...

Et Line Feed ou LF est le caractère de contrôle non imprimable qui fait tourner la platine (le cylindre principal en caoutchouc) d'une ligne.

Par conséquent, retour chariot et saut de ligne. Deux actions, et pendant des années, deux personnages de contrôle.

Chaque système d'exploitation semble encoder un EOL (fin de ligne) différemment. Les systèmes d'exploitation de la fin des années 70 utilisaient tous CR LF littéralement parce qu'ils s'interfaçaient quotidiennement avec des machines à écrire/imprimantes.

Windows utilise CRLF parce que DOS a utilisé CRLF parce que CP/M a utilisé CRLF parce que l'historique.

Mac OS a utilisé CR pendant des années jusqu'à ce que OS X passe à LF.

Unix n'utilisait qu'un seul LF sur CRLF et l'a fait depuis le début, probablement parce que des systèmes comme Multics ont commencé à n'utiliser que LF vers 1965. Enregistrer un seul octet CHAQUE LIGNE était une affaire énorme pour le stockage et la transmission.

Avance rapide jusqu'en 2018 et il est peut-être temps pour Windows de passer également à l'utilisation de LF comme caractère EOL pour les fichiers texte.

Pourquoi? Pour commencer, Microsoft a finalement mis à jour le Bloc-notes pour gérer les fichiers texte qui utilisent LF.

MAIS

Un tel changement serait-il possible ? Probablement pas, cela briserait le monde. Voici NewLine sur .NET Core.

public static String NewLine {
    get {
        Contract.Ensures(Contract.Result() != null);
#if !PLATFORM_UNIX
        return "\r\n";
#else
        return "\n";
#endif // !PLATFORM_UNIX
    }
}

Quoi qu'il en soit, si vous utilisez régulièrement Windows et WSL (Linux sur Windows) et Linux ensemble, vous voudrez être conscient et conscient de CRLF et LF.

J'ai rencontré une situation intéressante récemment. Voyons d'abord ce que fait Git

Vous pouvez configurer .gitattributes pour indiquer à Git comment traiter les fichiers, soit individuellement, soit par extension.

Quand

git config --global core.autocrlf true

est défini, git convertira automatiquement les fichiers silencieusement afin qu'ils soient extraits d'une manière spécifique au système d'exploitation. Si vous êtes sous Linux et que vous payez, vous obtiendrez LF, si vous êtes sous Windows, vous obtiendrez CRLF.

Viola sur Twitter offre une clarification importante :

"gitattributes contrôle le comportement de fin de ligne pour un référentiel, git config (en particulier avec --global) est un paramètre par utilisateur."

99% du système de temps et les options disponibles fonctionnent très bien.

Sauf lorsque vous partagez des systèmes de fichiers entre Linux et Windows. J'utilise Windows 10 et Ubuntu (via WSL) et je conserve les éléments dans /mnt/c/github.

Cependant, si je tire de Windows 10, j'obtiens CRLF et si je tire de Linux, je peux LF, alors mes scripts shell PEUVENT OU NE PEUVENT PAS FONCTIONNER dans Ubuntu.

J'ai choisi de créer un fichier .gitattributes qui définit à la fois les scripts shell et les scripts PowerShell sur LF. De cette façon, ces scripts peuvent être utilisés, partagés et exécutés entre les systèmes.

*.sh eol=lf
*.ps1 eol=lf

Vous avez beaucoup de choix. Encore une fois, 99% du temps, autocrlf est la bonne chose.

À partir de la documentation GitHub :

Vous remarquerez que les fichiers sont mis en correspondance--*.c , *.sln , *.png --, séparés par un espace, puis donné un paramètre--text , text eol=crlf , binary . Nous allons passer en revue quelques paramètres possibles ci-dessous.

• text=auto
  • Git gérera les fichiers de la manière qu'il jugera la meilleure. C'est une bonne option par défaut.
• text eol=crlf
  • Git convertira toujours les fins de ligne en CRLF à la caisse. Vous devez l'utiliser pour les fichiers qui doivent conserver CRLF fins, même sur OSX ou Linux.
• text eol=lf
  • Git convertira toujours les fins de ligne en LF à la caisse. Vous devriez l'utiliser pour les fichiers qui doivent conserver les terminaisons LF, même sous Windows.
• binary
  • Git comprendra que les fichiers spécifiés ne sont pas du texte, et il ne devrait pas essayer de les modifier. Le binary paramètre est également un alias pour -text -diff .

Encore une fois, les valeurs par défaut sont probablement correctes. MAIS - si vous faites des choses étranges, partagez des fichiers ou des systèmes de fichiers sur plusieurs systèmes d'exploitation, vous devez en être conscient.

Edward Thomson, co-responsable de libgit2, a ceci à dire et nous renvoie à son article de blog sur les fins de ligne.

Je dirais cela plus fortement. Étant donné que `core.autocrlf` est configuré dans une portée par utilisateur, mais affecte le fonctionnement de l'ensemble du référentiel, `.gitattributes` doit _toujours_ être utilisé.

Si vous rencontrez des problèmes, ce sont probablement les fins de ligne. La recommandation d'Edward est que TOUS les projets vérifient un .gitattributes.

La clé pour gérer les fins de ligne est de s'assurer que votre configuration est validée dans le référentiel, en utilisant .gitattributes . Pour la plupart des gens, c'est aussi simple que de créer un fichier nommé .gitattributes à la racine de votre dépôt qui contient une ligne :
* text=auto

J'espère que cela vous aidera !

* Machine à écrire de Matunos utilisée sous Creative Commons

Parrain : Découvrez JetBrains Rider :un IDE .NET multiplateforme. Modifiez, refactorisez, testez et déboguez des applications ASP.NET, .NET Framework, .NET Core, Xamarin ou Unity. En savoir plus et télécharger une version d'essai de 30 jours !