Diskussion zum Artikel "Erste Schritte mit MQL5 Algo Forge" - Seite 2
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Nein! Ein "Fork" und ein "Klon" sind nicht dasselbe. Bitte verwechseln Sie die beiden Begriffe nicht
Ich verstehe das vollkommen!
Der Grund, warum ich "clone" und nicht "fork" verwenden möchte, ist nicht Der Grund, warum ich "clone" und nicht "fork" verwenden möchte, ist nicht, dass ich meine eigene abgeleitete Arbeit daran ändern oder daran arbeiten möchte, sondern dass ich die ursprüngliche Arbeit und alle zukünftigen Aktualisierungen "verfolgen" und benachrichtigt werden möchte, wenn es neue "commits" gibt, die ich dann "ziehen" muss. Das ist der Grund für die Existenz der Funktion "Klonen".
MetaQuotes sollte also nicht eine "Fork" fördern und sie dann mit "Clone" einspielen. Es sollte ein "Fork" und dann ein "Pull" sein, nicht ein "Clone". Sie verwechseln die verschiedenen Funktionalitäten.
EDIT: Wenn MetaQuotes darauf besteht, eine "verkrüppelte" Git-Lösung zu implementieren und sie als "Feature" zu bezeichnen, dann wird es am Ende schlimmer als die bisherige SVN-Methode sein.
Was ich meinte, war, dass es bei einem Git-Klon eines Repositorys auf dem lokalen Rechner keinen Unterschied (in Bezug auf die Dateizusammensetzung und den Commit-Verlauf) zwischen dem Klonen aus dem ursprünglichen Repository und dem Klonen aus einem frischen Fork gibt.
In der Git-Dokumentation wird beschrieben, wie Sie Aktualisierungen aus dem Original-Repository in einen Klon Ihres Forks dieses Repositorys übernehmen können.Dies erfordert zumindest grundlegende Kenntnisse des Repositorys über eine Befehlszeilenschnittstelle. Die Möglichkeit, einen lokalen Klon von Code zu aktualisieren, istalso tatsächlich vorhanden. Um diesen lokalen Klon jedoch nur mit MetaEditor zu erstellen, müssen Sie in Ihrem Benutzerprofil einen Fork des ursprünglichen Repositorys erstellen. Erst wenn der Fork erstellt ist, wird sein Name in der Liste der gemeinsamen Projekte in MetaEditor angezeigt.
Im Allgemeinen mag ich diesen Ansatz nicht wirklich. Wenn wir nicht vorhaben, das Projektarchiv eines anderen Benutzers zu bearbeiten, brauchen wir keinen Fork, ein Klon des ursprünglichen Projektarchivs reicht aus. Ein Fork ist in diesem Fall ein zusätzlicher "Extra"-Eintrag in der Liste unserer Repositories. So wie ich es verstehe, erstellen wir einen Fork, wenn wir planen, aktiv Änderungen am Code aus dem ursprünglichen Repository vorzunehmen und wir erwarten nicht, dass diese Änderungen von unserem Fork in das ursprüngliche Repository übertragen werden (obwohl es eine solche Möglichkeit via Pull Request gibt).
Wenn wir uns in die Lage der MetaQuotes-Entwickler versetzen würden, könnten wir zum Beispiel einen separaten Ordner mit einem festen Namen, wie "Other Shared Projects", für Klone anderer Repositories einrichten. Aber diese Option hat ihre eigenen Nachteile, so dass sie wahrscheinlich noch schlechter ist als die derzeitige Lösung. Auf Anhieb fallen mir keine besseren Optionen ein. Vielleicht wird die Funktionalität von MetaEditor in der Zukunft erweitert, und wir werden eine andere Lösung präsentiert bekommen.
Ich würde gerne die Funktionalität des Updates testen. Deshalb habe ich einen Fork Ihres FMIC-Repositorys erstellt und es zu meiner Beobachtungsliste und meinen Favoriten hinzugefügt. Ich warte auf Ihren nächsten Commit, um zu sehen, wie ich es herausfinden kann, damit ich versuchen kann, den Fork zu aktualisieren.
Als Test habe ich eine Beschreibung der Heikin Ashi-Publikation in Form einer Markdown-README-Datei hinzugefügt und in das Repository übertragen.
Bitte schauen Sie, ob Sie über die Änderung benachrichtigt werden und ob Sie den Fork aktualisieren können.
MetaEditor ist auch nicht in der Lage, JPG-Bilddateien oder andere Dateitypen, die er als "unerkennbar" einstuft, zu übertragen, aber ich kann sie mit einem externen Git-Client übertragen.
PS! AlgoForge basiert auf der Open-Source-Software ForgeJo.
Zu Testzwecken habe ich eine Beschreibung der Heikin Ashi-Publikation als README-Datei im Markdown-Format hinzugefügt und in das Repository übertragen.
Bitte prüfen Sie, ob Sie eine Benachrichtigung über diese Änderung erhalten haben und ob Sie den Fork aktualisieren können.
Ich habe dies in der Webschnittstelle des Repositorys gesehen:
Ich werde versuchen, den Fork später zu aktualisieren
Zu Testzwecken habe ich eine Beschreibung der Heikin Ashi-Publikation als README-Datei im Markdown-Format hinzugefügt und in das Repository übertragen.
Bitte prüfen Sie, ob Sie eine Benachrichtigung über diese Änderung erhalten haben und ob Sie den Fork aktualisieren können.
Zunächst einmal hat mein lokaler Fork-Klon noch nicht den neuesten Commit:
Laut der Git-Dokumentation muss ich das ursprüngliche Repository verbinden:
Ich gehe auf die Weboberfläche des Forks und sehe dies:
Ich klicke auf die Schaltfläche "Sync" und mache dann einen Pull in MetaEditor:
Wie Sie sehen können, waren alle Ihre Commits sicher im Fork und dann nach Pull im Klon des Forks auf meinem lokalen Computer.
Auf dieser Dokumentationsseite gibt es noch andere Möglichkeiten, mit Konsolenbefehlen zu synchronisieren, aber ich habe sie nicht getestet, da alle Commits bereits synchronisiert sind.
Ich werde später mehr experimentieren, um zu sehen, wie sich der Commit- und Push-Befehl in MetaEditor für den Fork verhält. Ich frage mich, ob er versuchen wird, Änderungen auch an das ursprüngliche Repository zu senden.
Zunächst einmal hat mein lokaler Fork-Klon noch nicht den neuesten Commit:
Laut der Git-Dokumentation muss ich das Original-Repository verbinden:
Ich gehe auf die Weboberfläche des Forks und sehe dies:
Ich klicke auf die Schaltfläche "Sync" und führe dann einen Pull in MetaEditor durch:
Wie Sie sehen können, waren alle Ihre Commits sicher in der Fork und dann nach Pull in den Klon der Fork auf meinem lokalen Computer.
Auf dieser Seite der Dokumentation gibt es noch andere Möglichkeiten, mit Konsolenbefehlen zu synchronisieren, aber ich habe sie nicht getestet, weil alle Commits bereits synchronisiert sind.
Das ist alles schön und gut, aber Sie haben meinen Standpunkt bestätigt, dass ein "Clone" und ein "Fork" nicht dasselbe sind, und die Methode, die MetaQuotes übernommen hat, erfordert zusätzliche Eingriffe außerhalb von MetaEditor, nur um das Projekt synchronisieren zu können.
Ganz zu schweigen davon, daß für "Forks" zusätzlicher Speicherplatz auf den AlgoForge-Servern benötigt wird, während für einen "Clone" weder zusätzlicher Speicherplatz noch zusätzliche Schritte erforderlich sind.
Ich halte die MetaQuotes-Implementierungen für zu "fehlerhaft", um sie effektiv zu nutzen, und werde weiterhin einen externen Git-Client oder VSCode verwenden (was mit AlgoForge problemlos funktioniert).
Ich halte die MetaQuotes-Implementierungen für zu "fehlerhaft", um sie effektiv zu nutzen, und werde weiterhin einen externen Git-Client oder VSCode verwenden (was mit AlgoForge problemlos funktioniert).
Wir freuen uns, Sie in unserer Gemeinschaft der Nutzer externer Git-Clients begrüßen zu dürfen!😁
Ich finde die MetaQuotes-Implementierung zu "fehlerhaft", um sie effektiv zu nutzen, und werde weiterhin einen externen Git-Client oder VSCode verwenden (der mit AlgoForge problemlos funktioniert).
Leider ist dies im Moment tatsächlich der Fall. Auch ich ziehe es vor, im Moment einen externen Client zu verwenden. Aber wenn man vergleicht, was dem MetaEditor in den letzten 5 Monaten hinzugefügt wurde, ist es ein deutlicher Fortschritt. Es ist nur so, dass es vorher überhaupt keine Werkzeuge für die Arbeit mit dem neuen Repository gab, und jetzt gibt es zumindest eine solche reduzierte Version.