Diskussion zum Artikel "Umstellung auf MQL5 Algo Forge (Teil 2): Arbeiten mit mehreren Repositorys"
https://www.mql5.com/de/articles/17698
Vor dem Zusammenführen können wir noch einmal alle Änderungen in der praktischen Oberfläche des MQL5 Algo Forge Repository visuell überprüfen. Bei einer solchen gezielten Überprüfung fallen uns manchmal Dinge auf, die uns bei den Übertragungen entgangen sind: unnötige Kommentare, versehentlich hinzugefügte Dateien, suboptimale Änderungen. Im Grunde ist das eine Form der Selbstdisziplin. Außerdem gewöhnt man sich an die korrekten Abläufe und entwickelt die Gewohnheit, auf diese Weise zu arbeiten (Erstellung eines eigenen Zweigs, Code-Review, ...).
Lassen Sie mich raten, warum der Autor nicht demonstriert hat, wieman "Änderungen in der komfortablen Oberfläche des MQL5 Algo Forge Repositorys an zeigt". Weil der Autor es nicht tun kann, weil diff nicht funktioniert. Der Grund, warum diff nicht funktioniert, ist, dass Git Quellcode-Dateien als binär betrachtet. Sie können es sogar auf dem Screenshot aus dem Artikel sehen:
https://www.mql5.com/de/articles/17698
Damit ist der Zusammenführungsprozess abgeschlossen: Der Zweig article-17698-forge2wirdmit dem Zweig develop zusammengeführtund gelöscht:
Er wird nur vom Server entfernt, aber nicht aus MetaEditor (lokales Repository). Entweder hat der Autor versehentlich an der interessantesten Stelle aufgehört, oder es handelt sich um ein anderes Problem, über das er lieber schweigt.
[Es ist, als würde man einen Artikel über einen Sportwagen schreiben und vergessen, die Bremsen einzubauen. Beschreiben Sie, wie wunderbar er 300 km/h schnell fährt, aber lassen Sie die Tatsache weg, dass Sie nur anhalten können, wenn Sie gegen eine Mauer oder einen Baum fahren.Lassen Sie mich raten, warum der Autor die"Anzeige von Änderungen in der praktischen Schnittstelle des MQL5 Algo Forge Repository" nicht demonstriert hat. Weil der Autor es nicht tun kann, weil diff nicht funktioniert. Der Grund, warum diff nicht funktioniert, ist, dass Git Quellcode-Dateien als binär betrachtet. Sie können es sogar auf dem Screenshot aus dem Artikel sehen:
Man kann nicht alles auf einmal machen, leider. Dies ist kein Versuch, das Problem zu verbergen. Ich war mir fast sicher, dass es leicht behoben werden kann, deshalb habe ich es nicht hervorgehoben. Jetzt habe ich ein Experiment gemacht - ich habe eine Repository-Datei nach UTF-8 konvertiert. In ME lässt sie sich öffnen und kompilieren, ohne dass ein Unterschied zur UTF-16 LE-Datei besteht. In der Weboberfläche kann man die Unterschiede jetzt normal sehen. Im Allgemeinen ist esnicht Git, das Quellcodedateien als binär betrachtet, sondern eher die auf Forgejo basierende Weboberfläche, die nicht dafür ausgelegt ist, Textdateien in UTF-16 LE-Kodierung zu verarbeiten, die MetaEditor standardmäßig verwendet.
Aber diff in MetaEditor ist.... Offensichtlich kann es nur UTF-16 LE verwenden - russische Buchstaben einer Datei in UTF-8 werden nicht korrekt angezeigt und die gesamte Datei wird aufgrund von Unterschieden am Ende aller Zeilen als verändert angesehen:
Während des Schreibens des Artikels habe ich diff in ME nicht benutzt, weil... ich mir einfach angewöhnt habe, es zu benutzen, während ME Git-Unterstützung hinzufügte und VS Code für alle Operationen mit dem Repository parallel laufen lassen musste. Deshalb habe ich es nicht in den Artikel geschafft.
Ich versuche nicht ohne Grund, Alternativen vorzuschlagen, denn bisher hat ME noch Probleme mit Repositories. Gleichzeitig möchte ich aber auch daran glauben, dass diese Probleme mit der Zeit behoben werden. In der Zwischenzeit sollten wir das nutzen, was wir haben.
Es wird nur vom Server entfernt, aber nicht von MetaEditor (lokales Repository). Entweder hat der Autor versehentlich an der interessantesten Stelle aufgehört, oder es handelt sich um ein anderes Problem, über das er lieber schweigt.
Vielen Dank für den Hinweis. Wenn ein Zweig aus einem entfernten Repository gelöscht wird, sollte er nicht automatisch aus allen Klonen dieses Repositorys auf den lokalen Computern gelöscht werden. Er sollte in den lokalen Repositories separat gelöscht werden. Dies gilt für alle Git-basierten Repositories, es ist also kein Algo Forge Problem.
[Es ist, als würde man einen Artikel über einen Sportwagen schreiben, der vergessen hat, Bremsen einzubauen. Beschreiben Sie, wie wunderbar er mit 300 km/h fährt, aber lassen Sie die Tatsache weg, dass Sie nur anhalten können, wenn Sie gegen eine Wand oder einen schönen Baum fahren.
Oh, das ist ja klar! Die Fahrt ist außerordentlich ) Obwohl ich, um ehrlich zu sein, lieber nicht an jeder Ecke so stolpern würde. Es ist gut, dass es läuft. Und wo seine Bremsen nicht ausreichen, werden wir versuchen, externe Bremsen zu benutzen.
Im Allgemeinenist es nicht Git, das Quelldateien als Binärdateien betrachtet, sondern eher die Tatsache, dass die auf Forgejo basierende Weboberfläche nicht dafür ausgelegt ist, Textdateien in UTF-16 LE-Kodierung zu verarbeiten, was die von MetaEditor verwendete Standardkodierung ist.
Nein, Git selbst betrachtet Binärdateien mit der Kodierung, in der MetaEditor sie manchmal speichert. Weder forgejo noch seine Weboberfläche haben etwas damit zu tun. Der Beweis liegt in Ihrem Repository in Git Bash für Windows:
Nein, Git selbst betrachtet Binärdateien mit der Kodierung, in der MetaEditor sie manchmal speichert. Weder Forgejo noch seine Weboberfläche haben etwas damit zu tun. Der Beweis liegt in Ihrem Repository in Git Bash für Windows:
Trotzdem zeigt VS Code selbst in UTF-16 LE Kodierung ruhig alle Unterschiede an. Nun, Git selbst nennt sie binär.
Das Wichtigste, was wir herausgefunden haben, ist, dass nach der Konvertierung in UTF-8 das Problem in der Git-Konsole und im Web-Interface gelöst ist (aber es gibt ein anderes Problem in Diff ME):
Nein, Git selbst betrachtet Binärdateien mit der Kodierung, in der MetaEditor sie manchmal speichert. Weder Forgejo noch seine Weboberfläche haben etwas damit zu tun. Der Beweis liegt in Ihrem Repository in Git Bash für Windows:
Nachdem ich mir ein paar Tage den Kopf zerbrochen habe, ist es mir gelungen, einen Weg zu finden, um zumindest die Liste der "kaputten" Dateien aufzufüllen. Die Methode basiert auf der Tatsache, dass der Befehl
git ls-files --format='%(eolinfo:index) %(path)'
"-text" für sie anzeigt:
Aber dieser Befehl betrachtet nur den Index (geänderte und nicht verfolgte Dateien werden ignoriert). Ich habe mich nicht um die Besonderheiten von eolinfo gekümmert und beschlossen, dummerweise alle Dateien in den Index des neuen Repositorys aufzunehmen. Als Ergebnis habe ich ein Werkzeug entwickelt, mit dem man "kaputte" Dateien überprüfen kann, bevor sie gebrickt werden: https: //forge.mql5.io/boyvlad/mql-check-binary-surprises.
Logik der Anwendung: Kopieren Sie vor dem Commit alle Projektdateien (mit Ausnahme des .git-Ordners und der gitignore-Datei) in einen separaten Ordner und führen Sie das Skript (den Link dazu habe ich oben angegeben) darin aus. Das Skript listet die defekten Dateien auf, nachdem es zunächst ein neues Git-Repository initialisiert und alle Dateien dem Index hinzugefügt hat. Das Skript stellt zunächst sicher, dass der .git-Ordner und die gitignore-Dateien nicht vorhanden sind - ein Schutz gegen den versehentlichen Start im Arbeitsverzeichnis statt in einer Kopie davon.
Beispiel für die Verwendung:
Wir werden das Problem Schritt für Schritt beheben, einschließlich der Arbeit im Editor
Im Zuge der Verbesserung schlage ich vor, dass Sie einige Iterationen einer primitiven Verzweigungsstrategie nur mit MetaEditor und der Weboberfläche durchführen.
- Erstellen Sie den Zweig next, machen Sie dort ein paar Übertragungen
- next in main verschieben, next löschen
- Erstelle next erneut mit einer neuen übergeordneten Übergabe, mache ein paar Übergaben.
- ...
Punkt 3 ist derzeit nicht möglich, ohne externe Tools zu verwenden. Die Tatsache, dass Punkt 2 über die Website durchgeführt werden kann, macht es also nicht einfacher, weil es eine Sackgasse ist.
Ich habe in dieser Diskussion nichts Neues gesagt - ich habe bereits vor ein paar Monaten über all das berichtet. Jetzt kommt ein Artikel heraus, der die Punkte 1 und 2 abdeckt, aber zufälligerweise steht Punkt 3 nicht in dem Artikel (obwohl Punkt 3 eine logische Erweiterung ist).
Git ohne Branding ist wie Suppe ohne Brühe
Wir werden das Schritt für Schritt beheben, einschließlich der Arbeit im Editor.
Renat, können Sie mir sagen, ob es sinnvoll ist, alle Quellen auf UTF-8 umzustellen, oder wird ME sich weiterhin nur auf UTF-16 LE konzentrieren? Ich glaube, irgendwo in den Zweigen der neuen Builds oder irgendwo anders wurde die Umstellung auf UTF-8 erwähnt, aber vielleicht schien es?
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Neuer Artikel Umstellung auf MQL5 Algo Forge (Teil 2): Arbeiten mit mehreren Repositorys :
Im ersten Artikel haben wir mit der Umstellung von der integrierten SVN-basierten MQL5-Ablage in MetaEditor auf eine flexiblere und modernere Lösung auf der Grundlage des Versionskontrollsystems Git begonnen: MQL5 Algo Forge. Der Hauptgrund für diesen Schritt war die Notwendigkeit, Repository-Zweige bei der Arbeit an mehreren Projekten oder an verschiedenen Funktionen innerhalb eines einzelnen Projekts vollständig zu nutzen.
Der Übergang begann mit der Erstellung eines neuen Repositorys in MQL5 Algo Forge und der Einrichtung einer lokalen Entwicklungsumgebung mit Visual Studio Code, zusammen mit den notwendigen MQL5- und Git-Erweiterungen und unterstützenden Tools. Wir haben dann eine .gitignore-Datei zum Repository hinzugefügt, um Standard- und temporäre Dateien von der Versionskontrolle auszuschließen. Alle bestehenden Projekte wurden in einen eigenen Archivzweig hochgeladen, in dem der gesamte zuvor geschriebene Code archiviert wird. Der Hauptzweig wurde leer gelassen und für die Organisation neuer Projektzweige vorbereitet. Auf diese Weise haben wir die Grundlage für die Verteilung verschiedener Projektcodes auf verschiedene Zweige des Repositorys geschaffen.
Autor: Yuriy Bykov