1C-Company
Возможность выбора autocrlf по умолчанию
В связи с нововведениями в EDT 1.10 снова поднимаю вопрос о необходимости автоматически проставлять autocrlf при создании репозитория через конвертер.
В связи с этим нововведением - это тепеьр ответственность EDT или конвертера?
Все еще считаю, что стоит дать возможность пользователю настраивать это поведение для каждого элемента справочника "Хранилища", а не включать конвертацию по-умолчанию
В связи с нововведениями в EDT 1.10 снова поднимаю вопрос о необходимости автоматически проставлять autocrlf при создании репозитория через конвертер.
В связи с этим нововведением - это тепеьр ответственность EDT или конвертера?
Тут не надо путать 2 разные вещи:
- то, что выгружается в Конфигуратор,
- и то, что хранится в репозитории для разработки EDT.
Данный вопрос никак не связан с Конфигуратором - он связан с кросс-платформенной разработкой. Кросплатформенность - в 1С:Предприятии идет по умолчанию, т.о. мы должны заботиться о том, чтобы репозитории Git для этого подходили. Даже тогда, когда на начальном этапе разработчик 1С (настраивая ГитКонвертер) не задумывается об этом. Если в вашей среде все только (исключительно) виндовые пользователи - вы можете себе позволить принять такое соглашение и коммитить в репу с CRLF. Типовой инструмент не ограничивает вас в этом, но по умолчанию не должен создавать такую схему (имхо).
Я предлагаю, сделать расширением такую функциональность
@leemuar уточни, пожалуйста. Какое поведение сейчас, и какое ты ожидаешь?
@VladFrost я хочу, чтобы при настройке конвертации на форме была возможность явно включить или отключить эту опцию при создании репозитория. Чтобы использование этой опции было очевидно и прозрачно для пользователя, чтобы ее значение и использование не было скрыто и захардкожено
EDT позволяет работать корректно (и поддерживает по умолчанию) со переводами строк в разных ОС и единым репозиторием, но ты предлагаешь это отключить - и всем везде работать как в Linux? Верно я понимаю?
autocrlf требует настройки у каждого пользователя репозитория. без gitattributes autocrlf все равно ломает sh-скрипты до их полностью неработоспособного состояния. gitattributes настраивается один раз для всех и просто кладется в корень репы, разом решая проблемы вида "опять переносы строк поехали". но в целом да, я предлагаю работать в единых переводах строк под всеми системами, потому что все системы умеют работать с различными переводами строк вообще без каких-то проблем. и эта пляска win vs linux напрягает все больше, причем без какого-либо видимого профита для разработчика.
если так хочется, чтобы гитконвертер или едт сразу "настраивали разработчика" на хороший лад, то можно добавить генерацию гитаттрибутов при создании проекта (в случае гит конвертера) или в шаблон проекта для едт.
если так хочется, чтобы гитконвертер или едт сразу "настраивали разработчика" на хороший лад, то можно добавить генерацию гитаттрибутов при создании проекта (в случае гит конвертера) или в шаблон проекта для едт.
ГитКонвертер идет от мейнстрима EDT. Тут я мысль понял - передам коллегам из EDT идею. Если в EDT что-то поменяют - ГитКонвертер разу же адаптируем :)
Что касается текущих предложений - предлагаю сейчас уже сделать и настройки и генерацию атрибутов в расширении.
Я так полагаю, что эта настройка должна быть на всю базу ГитКонвертера, а не для каждой конкретной настройки хранилища. Можно сделать через ФО и/или макет дефолтных атрибутов конфига и/или макет для атрибутов. Наверное можно было бы сразу дать возможность переопределить через константу эти дефолтные настройки в рантайме...
перенесу из прошлой ветки свой ответ, чтобы контекст был полным:
Я тоже согласен с @nixel2007 - автоконвертация практически всегда ведет к проблемам. Одна из проблем - исправление окончаний строк в тех файлах, где это делать не нужно (макеты, например).
Сегодня практически все крупные текстовые редакторы умеют работать со всеми переводами строки на всех ОС, позволяют задать перевод строки по-умолчанию, в т.ч. для проекта.
Именно поэтому я использую переводы строки as-is - ровно в том виде, в котором из создает первоначальное приложение.
Я тоже согласен с @nixel2007 - автоконвертация практически всегда ведет к проблемам. Одна из проблем - исправление окончаний строк в тех файлах, где это делать не нужно (макеты, например).
Вот теперь (в 1.10) - это уже не проблема!
Я других проблем не знаю (все известные проблемы были решены в 1.10). Если есть - прошу тут описать.
Вот теперь (в 1.10) - это уже не проблема!
Так может тогда и выпилить из ядра конвертера в принципе? При создании репозитория средствами конвертера не указывать настройку autocrlf?