linux - Git på Windows: Hvad betyder crlf-indstillingerne?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg forstår ikke de kompleksiteter, der er relateret til CrLf-indstillinger i git: core.autocrlf, core.safecrlf


Jeg udvikler et tværplatformsprojekt i et hold og vil gerne have, at både Windows og Linux-udviklere kan arbejde sammen uden git-markeringsfiler som ændret bare på grund af line ending-stil.


Hvad betyder de forskellige indstillinger? Hvad ville konsekvenserne være ved at vælge en af ​​mulighederne? Og hvad ville være den bedste løsning for min sag?


Ja, jeg er opmærksom på dette spørgsmål og svarene der var ikke indsigtsfulde, og derfor ikke nyttige.

Bedste reference


De tre værdier for autocrlf:



  • true - Når indholdet går ind i depotet (er begået), bliver dets linjestykker konverteret til LF, og når indholdet kommer ud af lageret (tjekket ud), konverteres linjens slutninger til CRLF . Dette er generelt beregnet til clueless windows brugere/redaktører. I betragtning af antagelsen om, at en editor (eller bruger) vil oprette filer med CRLF-afslutninger, og vil freak ud, hvis det ser normale LF-slutninger, men at du vil have LF-afslutninger i repoet, vil dette forhåbentlig dække dig. Det er muligt for ting at gå galt, men. Der er eksempler på falske fusionskonflikter og rapporter om ændrede filer i de tilknyttede spørgsmål.

  • input - Når indholdet går ind i depotet, bliver dets linjestykker konverteret til LF, men indholdet forbliver uberørt på vej ud. Dette er stort set i samme rige som true, med den antagelse, at redaktørerne rent faktisk kan håndtere LF-slutninger korrekt; du 'bare vogter mod muligheden for ved et uheld at oprette en fil med CRLF-afslutninger.

  • false - git omhandler slet ikke linjestykker. Det er op til dig. Dette er, hvad mange mennesker anbefaler. Med denne indstilling, hvis en fils linjestykker bliver ødelagt, skal du være opmærksom på det, så fletningskonflikter er meget mindre tilbøjelige (under forudsætning af informerede brugere). Uddannelse udviklere om hvordan man bruger deres redaktører/IDE'er kan stort set tage sig af problemet. Alle de redaktører, jeg har set designet til programmører, er i stand til at håndtere dette, hvis de er konfigureret korrekt.



Bemærk at autocrlf ikke vil påvirke indhold, der er allerede i depotet. Hvis du har begået noget med CRLF-afslutninger tidligere, forbliver de på den måde. Dette er en meget god grund til at undgå, afhængigt af autocrlf; Hvis en bruger ikke har det indstillet, kan de få indhold med CRLF-slutninger i repo, og det vil holde sig. En stærkere måde at tvinge normalisering på er med tekstattributtet; sætter den til auto for en given sti, markerer den for normalisering i slutningen af ​​linjen, forudsat at git bestemmer indholdet er tekst (ikke binært). [18]


En beslægtet indstilling er safecrlf, som stort set kun er en måde at sikre, at du ikke utfører omvendt CRLF-konvertering på en binær fil.


Jeg har ikke masser af erfaring med Windows-problemer og git, så tilbagemeldinger om implikationer/faldgruber er helt sikkert velkomne.

Andre referencer 1


Jeg udforskede 3 mulige værdier for commit og checkout tilfælde og dette er den resulterende tabel:


╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║   git commit  ║ LF => LF     ║ LF => LF     ║ LF => LF     ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║  git checkout ║ LF => LF     ║ LF => LF     ║ LF => CRLF   ║
║               ║ CR => CR     ║ CR => CR     ║ CR => CR     ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝


Jeg vil anbefale at bruge core.autocrlf = input på tværs af alle platforme. I dette tilfælde, hvis Git står overfor CRLF, vil det implicit konvertere det til LF, og eksisterende filer med LF forbliver som det er.