Яка мета `text = auto` у файлі` .gitattributes`?


Відповіді:


77

З документів :

Кожен рядок у .gitattributes(або .git/info/attributes) файлі має форму:

pattern attr1 attr2 ...

Так ось, шаблон є *, що означає всі файли, а атрибут є text=auto.

Що робить text=auto? З документації:

Коли для тексту встановлено значення "авто", шлях позначається для автоматичної нормалізації кінця рядка. Якщо Git вирішить, що вміст - це текст, його закінчення нормалізуються на LF під час реєстрації.

Яка поведінка за замовчуванням, якщо вона не включена?

Не визначено

Якщо текстовий атрибут не визначений, Git використовує змінну конфігурації core.autocrlf, щоб визначити, чи слід перетворити файл.

Що робить core.autocrlf? З документів:

   core.autocrlf

Якщо встановити цю змінну на "true", це майже те саме, що встановити текстовий атрибут "auto" для всіх файлів, за винятком того, що текстові файли не гарантуються нормалізуватися: файли, що містять CRLF у сховищі, не будуть торкатися. Використовуйте це налаштування, якщо ви хочете мати у своєму робочому каталозі закінчення рядків CRLF, навіть якщо сховище не має нормалізованих закінчень рядків. Цю змінну можна встановити на вхід, і в цьому випадку перетворення вихідних даних не проводиться.

Якщо ви вважаєте, що все це зрозуміло, як грязь, ви не самотні.

Ось, що * text=autoстосується моїх слів: коли хтось робить файл, Git здогадується, що це файл - це текстовий файл чи ні, і якщо він є, він зробить версію файлу, де всі байти CR + LF замінені байтами LF. Це не впливає безпосередньо на те, як виглядають файли у робочому дереві, є й інші параметри, які перетворюють байт LF у байти CR + LF під час перевірки файлу.

Рекомендація:

Я б НЕ рекомендував покласти * text=autoв .gitattributesфайл. Натомість я б рекомендував щось подібне:

*.txt text
*.html text
*.css text
*.js text

Це явно позначає, які файли є текстовими файлами, які перетворюють CRLF в LF в об'єктній базі даних (але не обов'язково в робочому дереві). У нас відбулося репо * text=auto, і Гіт здогадався помилково для файлу зображення, що це текстовий файл, що призвело до його пошкодження, коли він замінив CR + LF байти на байти LF в об’єктній базі даних. Це не було весело налагоджувати.

Якщо вам потрібно скористатися * text=auto, поставте його як перший рядок .gitattributes, щоб наступні рядки могли його замінити. Це, здається, стає все більш популярною практикою.


2
Чому всі називають LF як звичайний, але не CRLF? Чи є якась спроба довести це?
Yousha Aleayoub

1
@YoushaAleayoub Що ти маєш на увазі?
Flimm

1
@YoushaAleayoub, якщо ви everyoneпосилаєтесь на git-scmце, це, мабуть, тому, що вони розробляють пакет * nix і, таким чином, використовують символ * nix newline - це нормально .
Джастін Мох

4
@YoushaAleayoub LF вважається "нормальним" b / c, це поширене в багатьох інструментах для розробників. Популярні інструменти для розробників, такі як git-scm* nix. MacOS використовує LF. Тільки Windows (враховуючи лише основні ОС) використовує CRLF. Це ускладнює розробникам програми за допомогою інструментів * nix у Windows та для всіх під час обміну файлами. Дивіться також Чому CRLF .
Рой Дантон

2
@Flimm, чи можете ви пояснити різницю між *.txt text=autoі *.txt textбудь ласка? Я подумав, що всі 4 рядки у вашому прикладі вище повинні були бути text=autoне лише textпісля розширення файлу. Наприклад, файли слідів KiCad (розширення ".kicad_mod") нормалізуються за допомогою цього рядка у файлі gitattributes: *.kicad_mod text=auto( kicad-pcb.org/libraries/klc/G1.7 ).
Габріель Степлес

64

Це забезпечує нормалізацію закінчень рядків. Джерело: Kernel.org

Коли текст встановлено на "авто", шлях позначається для автоматичної нормалізації кінця рядка. Якщо git вирішує, що вміст - це текст, його закінчення нормалізуються на LF під час реєстрації.

Якщо ви хочете взаємодіяти із системою управління вихідним кодом, яка застосовує нормалізацію кінця рядка, або ви просто хочете нормалізувати всі текстові файли у вашому сховищі, замість цього слід встановити текстовий атрибут на "авто" для всіх файлів.

Це гарантує, що всі файли, які git вважає текстовими, матимуть нормалізовані (LF) закінчення рядків у сховищі.


12
Що ви маєте на увазі під нормалізованим закінченням рядка?
Фізер Хан

14
When a text file is normalized, its line endings are converted to LF in the repository.
Дейв Зич

11
Важливо знати, це замінює локальну настройку core.autocrlf на вашій машині. Дивіться цю чудову відповідь від @Daniel Jomphe
spankmaster79

1
Було б дуже приємно, якби git просто не зробив $% # з будь-яким із файлів, що перевіряються у сховище. Я "працював зі SLM, PerForce, MsBuild, Source Depot, TFS, SVM, жоден з них не змінить навіть один байт у будь-якому з ваших файлів. Це підступний гейт-хак IMO, і він заподіяв мені багато болю.
Vance McCorkle

1
Що відбувається під час оформлення замовлення - це лише половина історії - що відбувається при отриманні? Чи правильно було б сказати, що під час оформлення замовлення закінчення рядків залишаються такими ж LF, навіть на windows?
Антоній

8

Ця конфігурація стосується того, як обробляються закінчення рядків. Якщо ввімкнено, усі закінчення рядків перетворюються на LF у сховищі. Існують і інші прапори, які стосуються того, як перетворюються закінчення рядків у вашому робочому каталозі. Повна інформація про проблему нам тут: https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.