Discussion de l'article "Passer à MQL5 Algo Forge (Partie 2) : Travailler avec plusieurs dépôts"
https://www.mql5.com/fr/articles/17698
Avant de fusionner , nous pouvons à nouveau examiner visuellement tous les changements dans l'interface pratique du dépôt MQL5 Algo Forge. Au cours d'une telle vérification, nous parvenons parfois à remarquer des choses qui ont échappé aux validations: des commentaires inutiles, des fichiers ajoutés accidentellement, des changements sous-optimaux. Il s'agit essentiellement d'une forme d'autodiscipline. En outre, le fait de s'habituer aux processus corrects développe l'habitude de travailler de cette manière (création d'une branche séparée, révision du code, ...).
Laissez-moi deviner pourquoi l'auteur n'a pas démontré"la visualisation des changements dans l'interface pratique du dépôt MQL5 Algo Forge". Parce que l'auteur ne peut pas le faire, parce que diff ne fonctionne pas. La raison pour laquelle diff ne fonctionne pas est que Git considère les fichiers de code source comme des fichiers binaires. Vous pouvez le voir même sur la capture d'écran de l'article :
https://www.mql5.com/fr/articles/17698
Ceci termine le processus de fusion : la branche article-17698-forge2est fusionnéedans la branche develop et supprimée :
Elle n'est supprimée que du serveur, mais pas de MetaEditor (dépôt local). Soit l'auteur s'est accidentellement arrêté au point le plus intéressant, soit il s'agit d'un autre problème qu'il a choisi de passer sous silence.
[C'est comme écrire un article sur une voiture de sport à laquelle on aurait oublié d'ajouter des freins. Décrivez la merveilleuse vitesse de 300 km/h, mais omettez le fait que vous ne pouvez vous arrêter que si vous percutez un mur ou un bon arbre.Laissez-moi deviner pourquoi l'auteur n'a pas démontré"la visualisation des changements dans l'interface pratique du dépôt MQL5 Algo Forge". Parce que l'auteur ne peut pas le faire parce que diff ne fonctionne pas. diff ne fonctionne pas parce que Git considère que les fichiers de code source sont binaires. Vous pouvez le voir même sur la capture d'écran de l'article :
On ne peut pas tout faire en même temps, malheureusement. Ce n'est pas une tentative de cacher le problème. J'étais presque sûr qu'il pouvait être facilement corrigé, donc je ne l'ai pas souligné. Maintenant, j'ai fait une expérience - j'ai converti un fichier de dépôt en UTF-8. Dans ME, il s'ouvre et se compile sans aucune différence par rapport à l'UTF-16 LE. Dans l'interface web, vous pouvez maintenant voir les différences normalement. En général, cen'est pas Git qui considère les fichiers de code source comme binaires, mais plutôt l'interface web basée sur Forgejo qui n'est pas conçue pour gérer les fichiers texte en encodage UTF-16 LE, que MetaEditor utilisait par défaut.
Mais le diff dans MetaEditor est.... Apparemment, il ne peut utiliser que l'UTF-16 LE - les lettres russes d'un fichier en UTF-8 ne sont pas affichées correctement et le fichier entier est considéré comme modifié à cause des différences à la fin de toutes les lignes :
Lors de la rédaction de l'article, je n'ai pas utilisé diff dans ME, parce que... J'ai simplement pris l'habitude de l'utiliser alors que ME ajoutait le support de Git et devait garder VS Code en parallèle pour toutes les opérations avec le dépôt. C'est pourquoi cela n'a pas été inclus dans l'article.
J'essaie de suggérer des méthodes alternatives pour une raison, parce que jusqu'à présent ME a toujours des problèmes avec les dépôts. Mais en même temps, je veux croire qu'ils seront corrigés avec le temps. En attendant, utilisons ce que nous avons.
Il n'est supprimé que du serveur, mais pas de MetaEditor (dépôt local). Soit l'auteur s'est accidentellement arrêté à l'endroit le plus intéressant, soit il s'agit d'un autre problème qu'il a préféré taire.
Merci pour la remarque. En effet, lorsqu'on supprime une branche d'un dépôt distant, elle ne doit pas être automatiquement supprimée de tous les clones de ce dépôt sur les ordinateurs locaux. Elle doit être supprimée séparément dans les dépôts locaux. Ceci est vrai pour tous les dépôts basés sur Git, ce n'est donc pas un problème propre à Algo Forge.
[C'est comme écrire un article sur une voiture de sport qui aurait oublié d'ajouter des freins. Décrivez la merveilleuse conduite à 300 km/h, mais omettez le fait que vous ne pouvez vous arrêter que si vous heurtez un mur ou un bel arbre.
Ça, c'est sûr ! La conduite est extraordinaire ) Même si, pour être honnête, je préférerais ne pas trébucher comme ça à chaque virage. C'est bon d'avancer. Et là où ses freins ne suffisent pas, nous essaierons d'utiliser des freins externes.
En général,ce n'est pas Git qui considère les fichiers sources comme binaires, mais plus probablement que l'interface web basée sur Forgejo n'est pas conçue pour gérer les fichiers textes en encodage UTF-16 LE, qui est l'encodage par défaut utilisé par MetaEditor.
Non, Git lui-même considère les fichiers binaires avec l'encodage dans lequel MetaEditor les enregistre parfois. Ni forgejo ni son interface web n'ont rien à voir avec cela. La preuve se trouve sur votre dépôt dans Git Bash pour Windows :
Non, Git lui-même considère les fichiers binaires avec l'encodage dans lequel MetaEditor les enregistre parfois. Ni forgejo ni son interface web n'ont quoi que ce soit à voir avec cela. La preuve se trouve sur votre dépôt dans Git Bash pour Windows :
Cependant, malgré cela, VS Code, même en encodage UTF-16 LE, montre calmement toutes les différences. En fait, Git lui-même les appelle binaires.
La principale chose que nous avons découverte est qu'après avoir converti en UTF-8, le problème est résolu dans la console Git et l'interface web (mais il y a un autre problème dans Diff ME) :
Non, Git lui-même considère les fichiers binaires avec l'encodage dans lequel MetaEditor les enregistre parfois. Ni forgejo ni son interface web n'ont quoi que ce soit à voir avec cela. La preuve se trouve sur votre dépôt dans Git Bash pour Windows :
Après m'être creusé la tête pendant quelques jours, j'ai réussi à trouver un moyen d'au moins compléter la liste des fichiers "cassés". La méthode est basée sur le fait que la commande
git ls-files --format='%(eolinfo:index) %(path)'
affiche "-text" pour eux :
Mais cette commande ne regarde que l'index (les fichiers modifiés et non suivis sont ignorés). Je ne me suis pas préoccupé des particularités d'eolinfo et j'ai décidé d'ajouter bêtement tous les fichiers à l'index du nouveau dépôt. En conséquence, j'ai créé un outil qui vous permet de vérifier les fichiers "cassés" avant qu'ils ne soient briques : https://forge.mql5.io/boyvlad/mql-check-binary-surprises.
Logique d'utilisation : avant de commiter, copiez tous les fichiers du projet (sauf le dossier .git et le fichier gitignore) dans un dossier séparé et exécutez le script (dont j'ai donné le lien plus haut) dans ce dossier. Le script listera les fichiers cassés, après avoir initialisé un nouveau dépôt git et ajouté tous les fichiers à l'index. Le script s'assurera d'abord que le dossier .git et les fichiers gitignore ne sont pas présents - protection contre le lancement accidentel dans le répertoire de travail au lieu d'une copie de celui-ci.
Exemple d'utilisation :
Nous allons le corriger étape par étape, y compris en travaillant dans l'éditeur.
Dans le processus d'amélioration, je vous suggère d'essayer d'effectuer quelques itérations d'une stratégie de branchement primitive en utilisant uniquement MetaEditor et l'interface web.
- Créer la branche next, y faire quelques commits
- Verser next dans main, supprimer next
- Créer next à nouveau avec un nouveau commit parent, faire quelques commits.
- ...
Le point 3 est actuellement impossible sans l'utilisation d'outils externes. Le fait que le point 2 puisse être réalisé via le site ne le rend pas plus facile, car c'est une impasse.
Je n'ai rien dit de nouveau dans cette discussion - j'ai déjà signalé tout cela il y a quelques mois. Il y a maintenant un article qui sort et qui couvre les points 1 et 2, mais il se trouve que le point 3 n'est pas dans l'article (bien que le point 3 soit une extension logique).
Git sans branding, c'est comme une soupe sans bouillon
Nous allons corriger la situation étape par étape, y compris dans l'éditeur.
Renat, pouvez-vous me dire s'il est judicieux de convertir toutes les sources à l'UTF-8 ou si ME continuera à se concentrer uniquement sur l'UTF-16 LE ? Je pense que quelque part dans les branches des nouvelles versions ou ailleurs, il a été mentionné le passage à l'UTF-8, mais peut-être que cela n'a pas été le cas ?
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Un nouvel article Passer à MQL5 Algo Forge (Partie 2) : Travailler avec plusieurs dépôts a été publié :
Dans le premier article, nous avons commencé la transition du stockage MQL5 Storage basé sur SVN dans MetaEditor vers une solution plus flexible et plus moderne basée sur le système de contrôle de version Git : MQL5 Algo Forge. La raison principale de cette étape était la nécessité d'exploiter pleinement les branches du dépôt tout en travaillant sur plusieurs projets ou sur différentes fonctionnalités au sein d'un même projet.
La transition a commencé par la création d'un nouveau dépôt dans MQL5 Algo Forge et la mise en place d'un environnement de développement local utilisant Visual Studio Code, ainsi que les extensions MQL5 et Git nécessaires et les outils supportés. Nous avons ensuite ajouté un fichier .gitignore au dépôt pour exclure les fichiers standards et temporaires du contrôle de version. Tous les projets existants ont été téléchargés dans une branche archive dédiée, désignée comme lieu d'archivage de tous les codes écrits précédemment. La branche main a été laissée vide et préparée pour l'organisation de nouvelles branches de projet. Nous avons ainsi jeté les bases de la distribution de différents codes de projet dans des branches distinctes du dépôt.
Auteur : Yuriy Bykov