Обсуждение статьи "Переходим на MQL5 Algo Forge (Часть 2): Работа с несколькими репозиториями" - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Предлагаю вам в процессе улучшения попробовать выполнить пару итераций какой-нибудь примитивной branching strategy используя только MetaEditor и веб интерфейс.
Пункт 3 на данный момент невозможен без использования внешних инструментов. Поэтому от того, что пункт 2 можно выполнить через сайт, легче вообще не становится, ведь дальше тупик.
Я ничего нового в этом обсуждении не сказал - я уже репортил все это пару месяцев назад. Теперь выходит статья, которая описывает пункты 1 и 2, но как-то так случайно совпало, что пункта 3 в статье нет (хотя пункт 3 является логическим продолжением).
Пункта 3 нет потому, что мне больше нравится подход, когда у веток разных фич названия разные, а не всегда одинаковое (next). При вашем подходе мне не понятно, зачем вообще удалять next? По смыслу она кажется похожей на ветку develop в связке main/develop, и используется для работы над каждой новой фичей при последовательном добавлении фич.
Проморочивши несколько дней голову, мне в свое время удалось найти способ хотябы залистить список "сломанных" файлов.
Да, я в своё время тоже заморочился скриптом очистки общего репозитория от всех скомпилированных файлов, который, как выяснилось, быстро оказался не нужен. Поскольку я не использовал веб-интерфейс для работы с отличиями файлов, то мне было неважно, что они там не отображали содержимое. Поэтому узнать список "сломаных" файлов можно, но зачем? Если и так известно, что это все файлы, создаваемые ME (в кодировке UTF-16 LE), то есть все файлы моих репозиториев за исключением README.md, .gitignore и еще пары каких-нибудь.
Ренат, можете сказать, есть ли смысл переконвертировать все исходники в UTF-8 или ME будет дальше ориентироваться только на UTF-16 LE? Вроде бы где-то в ветках новых билдов или где-то ещё упоминалось про переход на UTF-8, но может показалось?
О, создал только что в ME новый файл (New Class), так он создался сразу в UTF-8.
При вашем подходе мне не понятно, зачем вообще удалять next?
Я всегда удаляю branch сразу после того, как она была fully merged в branch более высокого уровня стабильности. Это уже привычка и я уверен, что это очень полезная привычка.
Чисто технически пересоздание бранча часто делает вполне осязаемую разницу в виде parent commit (родительский коммит следующего коммита). Иногда это некритично и влияет только на удобство восприятия commit graph, а иногда без пересоздания нельзя обойтись.
[edit]
Да и вообще я нахожу странным затею доказывать необходимость возможности удаления бранчей из локального репозитория. Учитывая, что Git’s branching model является его киллер фичей и Git поощряет частое создание, удаление и merging бранчей.
Поскольку я не использовал веб-интерфейс для работы с отличиями файлов, то мне было неважно, что они там не отображали содержимое.
Я тоже очень редко использую веб-интерфейс. И в MetaEditor никакие Git-кнопки не использую. diff смотрю в Git Bash for Windows - прямо в терминале - мне хватает и удобно.
Поэтому узнать список "сломаных" файлов можно, но зачем?
Узнать список сломанных файлов для того, чтобы их починить. Починить для того, чтобы можно было смотреть diff.
Для чего смотреть diff? [удалено малозначимое предложение, которое вызывало проблемы у автоматического переводчика]
Если и так известно, что это все файлы, создаваемые ME (в кодировке UTF-16 LE)
Я тестировал это пару месяцев назад. Визард создает UTF-8 (нормальные, не сломанные файлы). Даже MT4 визард создает нормальные файлы. Во время тех тестов мне ни разу не удалось получить от визарда "сломанный" файл.
Я иногда проверяю файлы тем скриптом перед коммитом. И, как оказалось, не зря - бывали случаи, когда нормальные файлы вдруг меняли кодировку. Возможно после вставки чего-нибудь из буффера обмена, я не знаю точно. Кириллица там вряд-ли была - я уже давно отказался от ее использования даже в комментариях.
Кириллица там вряд-ли была - я уже давно отказался от ее использования даже в комментариях.
Видимо я ошибался. Только что добавил в .mq5 файл с кодировкой UTF-8 вот это:
// Кириллицаи после сохранения кодировка файла сменилась на "UTF-16 LE BOM".
Похоже, это MetaEditor'а косяк. Я добавил кириллические символы и сохранил файл используя Notepad++ и кодировка осталась UTF-8.
Да и вообще я нахожу странным затею доказывать необходимость возможности удаления бранчей из локального репозитория. Учитывая, что Git’s branching model является его киллер фичей и Git поощряет частое создание, удаление и merging бранчей.
Так я же тоже за удаление веток после их слияния с основными ветками. Просто впервые услышал, что после удаления создают ветку под новую фичу не с новым, а с таким же именем.
Для чего смотреть diff?
Да, это очень нужная вещь. Тоже активно ей пользуюсь, но только в VS Code. А там, как ни странно, никаких поломок нет, хотя смотрю файлы с "плохой" кодировкой.
Не сталкивался с таким. Это тоже довольно неожиданно. Может, поломка нормальных файлов была связана с одновременным использованием разных билдов ME для работы с одними и теми же файлами? Не знаю...
Посмотрел по истории коммитов, что файлы, добавленные два месяца назад, действительно уже имеют кодировку UTF-8, а файлы, добавленные три месяца назад, - ещё UTF-16 LE. Видимо, где-то в это время был переход на кодировку UTF-8.
Видимо я ошибался. Только что добавил в .mq5 файл с кодировкой UTF-8 вот это:
и после сохранения кодировка файла сменилась на "UTF-16 LE BOM".
Похоже, это MetaEditor'а косяк. Я добавил кириллические символы и сохранил файл используя Notepad++ и кодировка осталась UTF-8.
Подтверждаю, после добавления русских букв и сохранения кодировка c UTF-8 меняется на UTF-16 LE. Если все русские буквы убрать и сохранить, то всё равно остаётся UTF-16 LE.
Похоже, это MetaEditor'а косяк.
Вот доказательство, что можно подружить UTF-8, кириллицу и Git:
https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea
Нужно лишь чтобы MQ попросили MetaEditor не изменять кодировку файла.