Waarom zou ik core.autocrlf=true in Git gebruiken?

Ik heb een Git-repository die toegankelijk is vanuit zowel Windows als OS X, en waarvan ik weet dat deze al enkele bestanden bevat met CRLF-regeleinden. Voor zover ik weet, zijn er twee manieren om hiermee om te gaan:

1. Stel core.autocrlfoveral in op false,

2. Volg de instructies hier(weergalmd op de helppagina’s van GitHub) om de repository te converteren zodat deze alleen LF-regeleinden bevat, en stel daarna core.autocrlfin op trueop Windows en inputop OS X. Het probleem hiermee is dat als ik binaire bestanden in de repository heb die:

   1. zijn niet correct gemarkeerd als binair in gitattributen, en
   2. bevatten zowel CRLF’s als LF’s,

   ze zullen beschadigd zijn. Het is mogelijk dat mijn repository dergelijke bestanden bevat.

Dus waarom zou ik Git’s regeleindconversie niet gewoon uitzetten? Er zijn veel vage waarschuwingen op het web over het uitschakelen van core.autocrlfen dit veroorzaakt problemen, maar zeer weinig specifieke; de enige die ik tot nu toe heb gevonden, is dat kdiff3 geen CRLF-uitgangen aankan (geen probleem voor mij), en dat sommige teksteditors problemen hebben met regeleinden (ook geen probleem voor mij).

De repository is intern voor mijn bedrijf, dus ik hoef me geen zorgen te maken over het delen met mensen met andere autocrlf-instellingen of regeleindevereisten.

Zijn er nog andere problemen met het gewoon laten van regeleinden zoals ze zijn waarvan ik me niet bewust ben?

Antwoord 1, autoriteit 100%

De enige specifieke redenen om autocrlfin te stellen op truezijn:

• vermijd dat de git statusal uw bestanden toont als modifiedvanwege de automatische EOL-conversie die wordt uitgevoerd bij het klonen van een Unix-gebaseerde EOL Git-repo naar een Windows-repo (zie uitgave 83bijvoorbeeld)
• enuw coderingstools zijn op de een of andere manier afhankelijk van een nativeEOL-stijl die aanwezig is in uw bestand:
  • bijvoorbeeld een codegenerator die hard gecodeerd is om native EOL te detecteren
  • andere externe batches (extern voor uw repo) met regexp of code die is ingesteld om native EOL te detecteren
  • Ik geloof dat sommige Eclipse-plug-ins bestanden met CRLF kunnen produceren, ongeacht het platform, wat een probleem kan zijn.
  • Je codeert met Notepad.exe (tenzij u een Windows 10 2018.09+ gebruikt, waarbij Kladblok het gedetecteerde EOL-teken respecteert).

Tenzij je een specifieke behandeling kunt zien die moetomgaan met native EOL, ben je beter af met autocrlfachterlatend op false(git config --global core.autocrlf false).

Merk op dat deze configuratie een lokaleconfiguratie zou zijn (omdat de configuratie niet van repo naar repo wordt gepusht)

Als je dezelfde configuratie wilt voor alle gebruikers die die repo klonen, ga dan naar “Wat is de beste CRLFverwerkingsstrategie met git?“, met behulp van het textattribuut in het .gitattributesbestand.

Voorbeeld:

*.vcproj    text eol=crlf
*.sh        text eol=lf

Opmerking: vanaf git 2.8 (maart 2016), zullen samenvoegmarkeringen niet langerhet gemengde regeleinde (LF) in een CRLF-bestand introduceren.
Zie “Laat Git CRLF gebruiken op zijn “<<<<<<<HEAD” samenvoegregels>”

Antwoord 2, autoriteit 19%

Ik ben een .NET-ontwikkelaar en gebruik Git en Visual Studio al jaren. Mijn sterke aanbeveling is om regeleindes op true in te stellen. En doe het zo vroeg mogelijk tijdens de levensduur van uw Repository.

Dat gezegd hebbende, ik HAAT het dat Git mijn regeleindes verandert. Bronbeheer mag alleen het werk dat ik doe opslaan en ophalen, het mag het NIET wijzigen. Ooit. Maar dat doet het wel.

Wat er zal gebeuren als je niet elke ontwikkelaar op true hebt ingesteld, is dat ÉÉN ontwikkelaar uiteindelijk op true zal worden ingesteld. Dit zal beginnen met het veranderen van de regeleindes van al uw bestanden naar LF in uw repo. En wanneer gebruikers deze onwaar instellen, zal Visual Studio u waarschuwen en u vragen deze te wijzigen. Er gebeuren heel snel 2 dingen. Ten eerste krijg je steeds meer van die waarschuwingen, hoe groter je team, hoe meer je krijgt. Het tweede, en ergere, is dat het zal laten zien dat elke regel van elk aangepast bestand is gewijzigd (omdat de regeleindes van elke regel door de echte man zullen worden gewijzigd). Uiteindelijk kunt u wijzigingen in uw repo niet meer betrouwbaar volgen. Het is VEEL gemakkelijker en schoner om iedereen voor waar te houden dan te proberen iedereen onwaar te houden. Hoe vreselijk het ook is om te leven met het feit dat uw vertrouwde bronbeheer iets doet wat het niet zou moeten doen. Ooit.

Antwoord 3, autoriteit 4%

Update 2:

Xcode 9 lijkt een “functie” te hebben waarbij het de huidige regeleindes van het bestand negeert, en in plaats daarvan gewoon je standaard regeleinde-instelling gebruikt bij het invoegen van regels in een bestand, wat resulteert in bestanden met gemengde regeleindes.

>

Ik ben er vrij zeker van dat deze bug niet bestond in Xcode 7; niet zeker over Xcode 8. Het goede nieuws is dat het opgelost lijkt te zijn in Xcode 10.

Voor de tijd dat het bestond, veroorzaakte deze bug een kleine hoeveelheid hilariteit in de codebase waarnaar ik verwijs in de vraag (die tot op de dag van vandaag autocrlf=falsegebruikt), en leidde tot veel “EOL ” berichten vast te leggen en uiteindelijk naar mijn schrijven van een git pre-commithook om te controleren op/voorkomen van het introduceren van gemengde regeleindes.

Bijwerken:

Opmerking: zoals opgemerkt door VonC, vanaf Git 2.8, zullen merge-markeringen nietUnix-stijl introduceren regeleinden naar een bestand in Windows-stijl.

Origineel:

Een kleine hapering die ik heb opgemerkt met deze opstelling is dat wanneer er samenvoegconflicten zijn, de regels die git toevoegt om de verschillen te markeren, geenregeleindes van Windows hebben, zelfs als de rest van het bestand doet, en je kunt eindigen met een bestand met gemengde regeleindes, bijvoorbeeld:

// Some code<CR><LF>
<<<<<<< Updated upstream<LF>
// Change A<CR><LF>
=======<LF>
// Change B<CR><LF>
>>>>>>> Stashed changes<LF>
// More code<CR><LF>

Dit levert voor ons geen problemen op (ik stel me voor dat elk hulpmiddel dat beide soorten regeleindes aankan, ook verstandig zal omgaan met gemengde regeleindes – zeker al degenen die we gebruiken), maar het is iets om te zijn bewust van.

Het andere dat we hebben gevonden^*, is dat wanneer we git diffgebruiken om wijzigingen te bekijken in een bestand met Windows-regeleinden, regels die zijn toegevoegd tonen hun regelterugloop, dus:

   // Not changed
+   // New line added in^M
+^M
    // Not changed
    // Not changed

_{* Het verdient niet echt de term: “probleem”.}

Antwoord 4

Voor mij.

Bewerk .gitattributes-bestand.

toevoegen

*.dll binary

Dan gaat alles goed.

Antwoord 5

Ik werk aan GitHub en vond dit artikelnuttig.

Het beschrijft de configuratie van git autocrlf en het .gitattributes-bestand met instellingen.