Discussion de l'article "Démarrer avec MQL5 Algo Forge" - page 2
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Non, un "fork" et un "clone" ne sont pas la même chose. Ne confondez pas ces deux concepts
Je comprends parfaitement !
La raison pour laquelle je veux utiliser "clone" et non "fork" est la suivante pas C'est parce que je veux "suivre" le travail original et toutes les futures mises à jour qui se produiront, et être notifié lorsqu'il y a de nouveaux "commits" que je dois alors "tirer". C'est la raison d'être de la fonctionnalité appelée "clone".
Ceci expliqué, MetaQuotes ne devrait pas promouvoir un "fork" et ensuite l'intégrer avec "clone". Il devrait s'agir d'un "fork" puis d'un "pull", et non d'un "clone". Ils mélangent les différentes fonctionnalités.
EDIT : Si MetaQuotes insiste pour implémenter une solution Git "paralysée", et l'appelle une "fonctionnalité", alors cela finira par être pire que l'ancienne méthode SVN.
Ce que je voulais dire, c'est que lorsqu'un clone git d'un dépôt est fait sur la machine locale, il n'y a pas de différence (dans la composition des fichiers et l'historique des livraisons) entre le clonage à partir du dépôt original et le clonage à partir d'un nouveau dépôt.
La documentation Git décrit comment vous pouvez obtenir des mises à jour du dépôt original dans un clone de votre fork de ce dépôt.Cela nécessite au moins des compétences de base en matière de dépôt via une interface de ligne de commande. Donc, en fait, la possibilité de mettre à jour un clone local de code existe bel et bien. Cependant, pour créer ce clone local en utilisant uniquement MetaEditor, vous devez créer une fourche du dépôt original dans votre profil d'utilisateur. Ce n'est qu'après la création de la fourche que son nom apparaîtra dans la liste des projets partagés dans MetaEditor.
En général, je n'aime pas vraiment cette approche. Après tout, si nous n'avons pas l'intention de modifier le dépôt de quelqu'un d'autre, nous n'avons pas besoin d'un fork, un clone du dépôt original est suffisant. Dans ce cas, un fork est un élément "supplémentaire" dans la liste de nos dépôts. Si je comprends bien, nous créons une fourche lorsque nous prévoyons d'apporter activement des modifications au code du dépôt original et que nous ne nous attendons pas à ce que ces modifications soient transférées de notre fourche au dépôt original (bien qu'il y ait une telle possibilité via une Pull Request).
En nous mettant à la place des développeurs de MetaQuotes, nous pourrions, par exemple, ajouter un dossier séparé avec un nom fixe, comme "Other Shared Projects", pour les clones d'autres dépôts. Mais cette option a ses propres inconvénients, et elle est donc probablement encore pire que la solution actuelle. Je ne vois pas de meilleures options pour l'instant. Peut-être que les fonctionnalités de MetaEditor seront étendues dans le futur et qu'une autre solution nous sera présentée.
J'aimerais tester la fonctionnalité de la mise à jour. C'est pourquoi j'ai créé une fourche de votre dépôt FMIC, je l'ai ajouté à ma liste de surveillance et à mes favoris. J'attendrai votre prochain commit pour voir comment je peux le découvrir afin d'essayer de mettre à jour le fork.
Comme test, j'ai ajouté une description de la publication Heikin Ashi, en tant que fichier README Markdown, et je l'ai ajouté au dépôt.
S'il vous plaît, voyez si vous êtes informé du changement et si vous êtes en mesure de mettre à jour la fourche.
MetaEditor est également incapable de livrer des fichiers image JPG ou tout autre type de fichier qu'il juge "non reconnaissable", mais je peux les livrer en utilisant un client Git externe.
PS ! AlgoForge est basé sur le logiciel open source ForgeJo.
À titre de test, j'ai ajouté une description de la publication Heikin Ashi en tant que fichier README au format Markdown et je l'ai intégré au dépôt.
Veuillez vérifier si vous avez reçu une notification de ce changement et si vous pouvez mettre à jour la fourche.
J'ai vu cela dans l'interface web du dépôt :
J'essaierai de mettre à jour la fourche plus tard
À titre de test, j'ai ajouté une description de la publication Heikin Ashi en tant que fichier README au format Markdown et je l'ai intégré au dépôt.
Veuillez vérifier si vous avez reçu une notification de ce changement et si vous pouvez mettre à jour la fourche.
Tout d'abord, mon clone local n'a pas encore le dernier commit :
Connecter le dépôt original, selon la documentation Git :
Je vais sur l'interface web de la fourche et je vois ceci :
Je clique sur le bouton "Sync" et je fais un Pull dans MetaEditor :
Comme vous pouvez le voir, tous vos commits étaient en sécurité dans la fourche et après Pull dans le clone de la fourche sur mon ordinateur local.
Sur cette page de documentation, il y a d'autres façons de synchroniser en utilisant les commandes de la console, mais je ne les ai pas testées, car tous les commits sont déjà synchronisés.
J'expérimenterai plus tard pour voir comment les commandes Commit et Push de MetaEditor se comporteront pour le fork. Je me demande s'il essaiera d'envoyer les modifications au dépôt original également.
Tout d'abord, mon clone local n'a pas encore le dernier commit :
Connecter le dépôt original, selon la documentation Git :
Je vais sur l'interface web du fork et je vois ceci :
Je clique sur le bouton "Sync" et je fais un Pull dans MetaEditor :
Comme vous pouvez le voir, tous vos commits étaient en sécurité dans la fourche et après Pull dans le clone de la fourche sur mon ordinateur local.
Sur cette page de la documentation, il y a d'autres façons de synchroniser en utilisant les commandes de la console, mais je ne les ai pas testées, parce que tous les commits sont déjà synchronisés.
Tout cela est très bien, mais vous avez prouvé mon point de vue qu'un "Clone" et un "Fork" ne sont pas les mêmes, et la méthode que MetaQuotes a adoptée nécessite une intervention supplémentaire en dehors de MetaEditor juste pour être en mesure de synchroniser le projet.
Sans compter qu'elle nécessite un espace de stockage supplémentaire sur les serveurs d'AlgoForge, pour les "forks", alors qu'un "clone" ne nécessite pas de stockage supplémentaire ni d'étapes supplémentaires.
Je considère que les implémentations de MetaQuotes sont trop "défectueuses" pour être utilisées efficacement et je continuerai à utiliser un client Git externe, ou à utiliser VSCode (qui fonctionne parfaitement avec AlgoForge sans aucun problème).
Je considère que les implémentations de MetaQuotes sont trop "imparfaites" pour une utilisation efficace et je continuerai à utiliser un client Git externe, ou à utiliser VSCode (qui fonctionne parfaitement avec AlgoForge sans aucun problème).
Nous sommes heureux de vous accueillir dans notre communauté d'utilisateurs de clients Git externes!😁
Je trouve l'implémentation de MetaQuotes trop "imparfaite" pour l'utiliser efficacement et je continuerai à utiliser un client Git externe ou VSCode (qui fonctionne parfaitement avec AlgoForge sans aucun problème).
Malheureusement, c'est effectivement le cas pour l'instant. Je préfère moi aussi utiliser un client externe pour le moment. Mais si vous comparez ce qui a été ajouté à MetaEditor au cours des 5 derniers mois, c'est un progrès notable. C'est juste qu'avant il n'y avait pas du tout d'outils pour travailler avec le nouveau dépôt, et maintenant il y a au moins une version réduite.