Kodėl turėčiau naudoti core.autocrlf = true?

Turiu „Git“ saugyklą, kuri pasiekiama iš „Windows“ ir „OS X“, ir jau žinoma, kad jau yra keletas failų su CRLF linijų galais. Kiek galiu pasakyti, tai yra du būdai:

  • core.autocrlf nustatykite core.autocrlf false

  • Laikykitės čia pateiktų nurodymų (atkartokite „GitHub“ pagalbos puslapiuose), jei norite konvertuoti saugyklą tik į LF linijų galų sąrašą, tada nustatykite core.autocrlf „Windows“ ir core.autocrlf į „OS X“. kai kurie saugyklos binarai, kurie:

    • neteisingai pažymėti kaip dvejetainiai gitattributes, ir
    • yra CRLF ir LF,

    jie bus sugadinti. Galbūt mano saugykloje yra tokių failų.

Tad kodėl aš ne tik išjungiu „Git“ linijos pertrauką? Yra daug neaiškių įspėjimų apie pagrindinį „ core.autocrlf uždarymą core.autocrlf , sukeliančius problemų, tačiau labai mažai konkrečių; vienintelis dalykas, kurį iki šiol radau, yra tai, kad kdiff3 negali apdoroti CRLF terminų (tai nėra problema man) ir kad kai kurie teksto redaktoriai turi problemų su linijos pabaiga (taip pat man tai nėra problema).

Duomenų saugykla yra mano įmonės vidinė, taigi nereikia jaudintis dėl dalijimosi su žmonėmis, turinčiais skirtingus automatinio nustatymo nustatymus ar linijos užbaigimo reikalavimus.

Ar yra kokių nors kitų problemų, susijusių su linijos galų išėjimu, nes nežinau?

238
13 мая '10 в 11:50 2010-05-13 11:50 Turtingas yra nustatytas gegužės 13 d., 10 val., 11:50, 2010-05-13 11:50
@ 3 atsakymai

Vienintelės konkrečios priežastys, kodėl autocrlf , true :

  • Venkite „ git status rodydami visus modified failus, atliktus dėl automatinio „EOL“ konversijos, atliekamą klonuojant „Unix“ pagrindu veikiančią EOL GIT saugyklą sistemoje „Windows“ (pvz., Žr. Leidimą 83 )
  • ir jūsų kodavimo įrankiai kažkaip priklauso nuo to, kokiame EOL stiliuje yra jūsų failas:

Jei nematote konkretaus apdorojimo, kuris turėtų būti susijęs su vietine EOL, geriau palikti autocrlf false .

Atkreipkite dėmesį, kad ši konfigūracija bus vietinė (nes konfigūracija perkeliama iš repo į repo)

Jei jums reikia tos pačios konfigūracijos visiems naudotojams, kurie klonuoja šį saugyklą, žr. „ Kas yra geriausia CRLF tvarkymo strategija suCRLF ? , text atributo naudojimas .gitattributes faile .


Pastaba: pradedant nuo 2.8 gitos (2016 m. Kovo mėn.), Sujungimo žymekliai nebebus įvesti mišrios eilutės (LF) CRLF faile.
Žr. „ Padarykite„ Git “naudodami CRLF“. <<<<<<< HEAD „sujungti eilutes

181
13 мая '10 в 12:55 2010-05-13 12:55 atsakymą pateikė „ VonC “ gegužės 13 d. 10 val. 12:55 2010-05-13 12:55

Susiję klausimai


Susiję klausimai

Aš .NET kūrėjas ir keletą metų naudojasi „Git“ ir „Visual Studio“. Mano stipri rekomendacija yra nustatyti liniją, kuri baigtųsi tiesa. Ir tai atlikite kuo anksčiau savo saugyklos gyvavimo metu.

Tuo pačiu metu, HATE, kad Git keičia linijos pabaigą. Pradinė kontrolė turėtų išsaugoti ir atkurti tik tai, ką darau, ji neturėtų pakeisti. Visada Bet tai yra.

Kas atsitiks, jei kiekvienas kūrėjas neturi tikrosios vertės, ONE kūrėjas galiausiai nustatys tikrąją vertę. Tai pradės keisti visų failų linijų, esančių „LF“ repo, pabaigą. O kai vartotojai nustato klaidingą, patikrinkite, ar „Visual Studio“ jus įspės ir paprašys juos pakeisti. Jūs turėsite 2 dalykus, kurie atsitiks labai greitai. Pirma, gausite daugiau ir daugiau šių įspėjimų, tuo daugiau jūsų komandos, tuo daugiau gausite. Antrasis, o dar blogiau, parodys, kad kiekvienos pakeistos rinkmenos eilutė buvo pakeista (nes kiekvienos eilutės linijų pabaiga bus pakeista tikruoju vaikinu). Galų gale, nebegali stebėti repo pakeitimų. Tai daug lengviau ir švariau, kad visi liktų ištikimi, nei stengtųsi išlaikyti visus netinkamą šviesą. Kaip baisi, nes jums reikia gyventi su tuo, kad jūsų patikimas kontrolės šaltinis daro kažką, ko neturėtų. Kažkada

22
10 июня '16 в 16:23 2016-06-10 16:23 Atsakymą pateikė JGTaylor birželio 16 d. 16:23 2016-06-10 16:23

Atnaujinti

Pastaba Kaip pažymėjo VonC, pradedant Git 2.8, sujungimo žymekliai neišsiųs Unix stiliaus eilutės į Windows stiliaus failą .

Originalas

Vienas nedidelis svyravimas, kurį pastebėjau su šiuo nustatymu, yra tai, kad įvykus susiliejimo konfliktams pridedamos „Git“ eilutės, kad būtų pažymėti skirtumai, jie neturi „Windows“ linijų, net jei likęs failas ir galite gauti failą su mišriomis eilutėmis :

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

Tai mums nesukelia jokių problemų (manau, kad bet kuris įrankis, galintis valdyti abu styginių tipus, taip pat bus prasmingas su mišriais linijos galais - žinoma, visi tie, kuriuos mes naudojame), bet tai yra kažkas panašaus į realizavimą.

Kitas dalykas, kurį mes nustatėme, buvo tai, kad naudojant „ git diff norėdami peržiūrėti failo pakeitimus su linijos pabaiga, pridėtos „Windows“ linijos rodo jų vežimo grąžą, taigi

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

* Tai tikrai nereiškia, kad terminas „problema“.

12
16 янв. Atsakymas duotas Rich 16 Jan. 2012-01-16 19:50 '12, 07:50 pm 2012-01-16 19:50

Žr. Kitus klausimus apie „ arba „ Ask a question“