Обсуждение статьи "Переходим на MQL5 Algo Forge (Часть 2): Работа с несколькими репозиториями"
https://www.mql5.com/ru/articles/17698
Перед слиянием мы ещё раз можем визуально просмотреть все изменения в удобном интерфейсе хранилища MQL5 Algo Forge. При такой целенаправленной проверке порой удаётся заметить вещи, которые ускользнули при коммитах: лишние комментарии, случайно добавленные файлы, неоптимальные изменения. По сути, это некоторая форма самодисциплины. К тому же привыкание к правильным процессам вырабатывает привычку работать именно таким образом (создание отдельной ветки, код-ревью, ...).
Дайте угадаю, почему автор не продемонстрировал "просмотр изменений в удобном интерфейсе хранилища MQL5 Algo Forge". Потому, что автор не может этого сделать, так как diff не работает. diff не работает потмоу, что Git считает файлы с исходным кодом бинарными. Это видно даже на скриншоте со статьи:
https://www.mql5.com/ru/articles/17698
На этом процесс слияния завершён: ветка article-17698-forge2 влита в ветку develop и удалена:
Она удалена только с сервера, но не из MetaEditor (локального репозитория). Либо автор случайно остановился на самом интересном месте, либо это еще одна проблема, о которой предпочли умолчать.
[edit] Это все равно, что писать статью о спорткаре, в который забыли добавить тормоза. Описать как чудесно он едет 300 км/час, но умолчать о том, что остановка возможна только если впечататься в какую-нибудь стену или хорошее дерево.Дайте угадаю, почему автор не продемонстрировал "просмотр изменений в удобном интерфейсе хранилища MQL5 Algo Forge". Потому, что автор не может этого сделать, так как diff не работает. diff не работает потмоу, что Git считает файлы с исходным кодом бинарными. Это видно даже на скриншоте со статьи:
Всё сразу успеть не получается, к сожалению. Это не попытка спрятать проблему. Был почти уверен, что это можно легко починить, поэтому не стал акцентировать на этом внимание. Сейчас провёл эксперимент - конвертировал один файл репозитория в UTF-8. В ME он открывается и компилируется без каких-либо отличий от того времени, когда он был в UTF-16 LE. В веб-интерфейсе теперь можно нормально посмотреть отличия. В общем, это не Git считает файлы с исходным кодом бинарными, а больше похоже на то, что веб-интерфейс на основе Forgejo не рассчитан на обработку текстовых файлов в кодировке UTF-16 LE, которую использовал MetaEditor по-умолчанию.
А вот diff в MetaEditor... Ему, видимо, только UTF-16 LE подавать можно - русские буквы файла в UTF-8 не отображаются корректно и весь файл считается изменённым из-за различий в конце всех строк:
В процессе написания статьи не пользовался diff в ME, так как... да просто отвык им пользоваться за то время, пока в ME добавлялась поддержка Git и приходилось держать параллельно запущенный VS Code для всех операций с репозиторием. Поэтому и не попало это в статью.
Я не зря пытаюсь предложить альтернативные способы, так как пока проблемы в ME по работе с репозиториями остаются. Но в то же время хочется верить, что они тоже будут со временем устранены. А пока - используем то, что есть.
Она удалена только с сервера, но не из MetaEditor (локального репозитория). Либо автор случайно остановился на самом интересном месте, либо это еще одна проблема, о которой предпочли умолчать.
Спасибо за замечание. Действительно, при удалении ветки из удаленного репозитория она и не должна автоматически удаляться из всех клонов этого репозитория на локальных компьютерах. В локальных репозиториях её надо удалить отдельно. Это так во всех хранилищах на основе Git, так что это не проблема Algo Forge.
[edit] Это все равно, что писать статью о спорткаре, в который забыли добавить тормоза. Описать как чудесно он едет 300 км/час, но умолчать о том, что остановка возможна только если впечататься в какую-нибудь стену или хорошее дерево.
Вот уж точно! Драйв необыкновенный ) Хотя, честно говоря, предпочёл бы не спотыкаться так на каждом повороте. Хорошо, что едет. А где его тормозов не хватает, будем стараться использовать внешние тормоза.
В общем, это не Git считает файлы с исходным кодом бинарными, а больше похоже на то, что веб-интерфейс на основе Forgejo не рассчитан на обработку текстовых файлов в кодировке UTF-16 LE, которую использовал MetaEditor по-умолчанию.
Нет, сам Git считает бинарными файлы с кодировкой, в которой их иногда сохраняет MetaEditor. Ни forgejo, ни его веб интерфейс здесь ни при чем. Доказательство на вашем репозитории в Git Bash for Windows:
Нет, сам Git считает бинарными файлы с кодировкой, в которой их иногда сохраняет MetaEditor. Ни forgejo, ни его веб интерфейс здесь ни при чем. Доказательство на вашем репозитории в Git Bash for Windows:
Тем не менее, несмотря на это VS Code даже в кодировке UTF-16 LE спокойно показывает все различия. Ну а сам Git называет их бинарными.
Главное мы выяснили, что после конвертации в UTF-8 проблема решается в консоли Git и в веб-интерфейсе (но при этом возникает другая проблема в Diff ME):
Нет, сам Git считает бинарными файлы с кодировкой, в которой их иногда сохраняет MetaEditor. Ни forgejo, ни его веб интерфейс здесь ни при чем. Доказательство на вашем репозитории в Git Bash for Windows:
Проморочивши несколько дней голову, мне в свое время удалось найти способ хотябы залистить список "сломанных" файлов. Способ основан на том, что команда
git ls-files --format='%(eolinfo:index) %(path)'
отображает для них "-text":
Но та команда смотрит только в index (modified и untracked файлы игнорируются). Я не стал разбираться с особенностями eolinfo и решил втупую добавить все файлы в index нового репозитория. В итоге я навайбкодил себе приблуду, которая позволяет проверить наличие "сломанных" файлов до того, как они будут закомичены: https://forge.mql5.io/boyvlad/mql-check-binary-surprises
Логика использования: прежде чем делать коммит, скопировать все файлы проекта (кроме .git папки и gitignore файла) в отдельную папку и запустить в ней скрипт (ссылку на который я дал выше). Скрипт выведет список сломанных файлов, предварительно инициализировав новый git репозиторий и добавив все файлы в index. Скрипт предварительно убедится, что .git папки и gitignore файлов нет - защита от случайного запуска в рабочем каталоге вместо его копии.
Пример использования:
Будем исправлять шаг за шагом, включая работу в редакторе
Предлагаю вам в процессе улучшения попробовать выполнить пару итераций какой-нибудь примитивной branching strategy используя только MetaEditor и веб интерфейс.
- Создали ветку next, сделали туда пару коммитов
- Влили next в main, удалили next
- Создали next еще раз с новым parent commit, сделали пару коммитов
- ...
Пункт 3 на данный момент невозможен без использования внешних инструментов. Поэтому от того, что пункт 2 можно выполнить через сайт, легче вообще не становится, ведь дальше тупик.
Я ничего нового в этом обсуждении не сказал - я уже репортил все это пару месяцев назад. Теперь выходит статья, которая описывает пункты 1 и 2, но как-то так случайно совпало, что пункта 3 в статье нет (хотя пункт 3 является логическим продолжением).
Git без бренчинга это как суп без бульона
Будем исправлять шаг за шагом, включая работу в редакторе
Ренат, можете сказать, есть ли смысл переконвертировать все исходники в UTF-8 или ME будет дальше ориентироваться только на UTF-16 LE? Вроде бы где-то в ветках новых билдов или где-то ещё упоминалось про переход на UTF-8, но может показалось?
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Опубликована статья Переходим на MQL5 Algo Forge (Часть 2): Работа с несколькими репозиториями:
Рассмотрим один из возможных подходов к организации хранения исходного кода проекта в публичном репозитории. Используя распределение по различным веткам, создадим удобные и понятные правила для развития проекта.
В первой статье мы начали переход от использования MQL5 Storage — встроенного SVN-хранилища в MetaEditor — к более гибкому и современному решению на основе системы контроля версий Git — MQL5 Algo Forge. Основной причиной такого шага стало желание полноценно использовать разные ветки репозитория в процессе работы над разными проектами или функциональностью в рамках одного проекта.
Переход начался с создания нового репозитория в MQL5 Algo Forge и настройки локальной среды разработки с использованием Visual Studio Code, соответствующих расширений для работы с MQL5 и Git, а также установки необходимых инструментов. После этого в созданном репозитории мы добавили файл .gitignore для исключения из отслеживания стандартных и временных файлов. Все текущие проекты были загружены в отдельную ветку archive, которой была отведена роль архивного хранилища всего существующего кода. Основная ветка main была оставлена пустой и подготовлена для организации новых проектных веток. Таким образом, были заложены все необходимые основы для дальнейшего распределения кода разных проектов по разным веткам репозитория.
Автор: Yuriy Bykov