Обсуждение статьи "Переходим на 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 не изменять кодировку файла.