Discussion de l'article "Passer à MQL5 Algo Forge (Partie 2) : Travailler avec plusieurs dépôts" - 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
Je vous suggère, dans le cadre du processus d'amélioration, d'essayer d'effectuer quelques itérations d'une stratégie de branchement primitive en utilisant uniquement le MetaEditor et l'interface web.
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 décrit les points 1 et 2, mais il se trouve que le point 3 ne figure pas dans l'article (bien que le point 3 soit une suite logique).
Le point 3 est absent parce que je préfère l'approche où les branches des différentes caractéristiques ont des noms différents, pas toujours les mêmes (suivant). Avec votre approche, je ne vois pas très bien pourquoi next devrait être supprimé. Sa signification semble similaire à celle de la branche develop dans le paquet main/develop, et elle est utilisée pour travailler sur chaque nouvelle fonctionnalité lors de l'ajout séquentiel de fonctionnalités.
Après quelques jours de réflexion, j'ai réussi à trouver un moyen de compléter la liste des fichiers "cassés".
Oui, à un moment donné, j'ai également essayé un script pour vider le référentiel commun de tous les fichiers compilés, ce qui, comme il s'est avéré, s'est rapidement avéré inutile. Comme je n'utilisais pas l'interface web pour traiter les différences de fichiers, je ne me souciais pas du fait qu'ils n'affichaient pas le contenu à cet endroit. Il est donc possible de trouver la liste des fichiers "cassés", mais pourquoi ? Si l'on sait déjà qu'il s'agit de tous les fichiers créés par ME (encodés en UTF-16 LE), il s'agit de tous les fichiers de mon dépôt à l'exception de README.md, .gitignore et quelques autres.
Renat, pouvez-vous me dire s'il est judicieux de convertir toutes les sources en UTF-8 ou si ME continuera à être orienté 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 ?
Oh, je viens de créer un nouveau fichier dans ME (New Class), il a donc été créé immédiatement en UTF-8.
Avec votre approche, je ne vois pas très bien pourquoi vous supprimeriez la branche suivante ?
Je supprime toujours une branche immédiatement après qu'elle ait été entièrement fusionnée dans une branche d'un niveau de stabilité supérieur. C'est une habitude et je suis sûr qu'elle est très utile.
D'un point de vue purement technique, la reconstruction d'une branche fait souvent une différence tangible sous la forme d'un commit parent (commit parent du commit suivant). Parfois, cela n'est pas critique et n'affecte que la facilité d'utilisation du graphe des livraisons, et parfois vous ne pouvez pas vous passer de recréer.
[éditer]
En général, je trouve étrange de soutenir qu'il est nécessaire de pouvoir supprimer des branches du dépôt local. Étant donné que le modèle de branchement de Git est sa principale caractéristique et que Git encourage la création, la suppression et la fusion fréquentes de branches, je trouve étrange de soutenir qu'il est nécessaire de pouvoir supprimer les branches du dépôt local.
Comme je n'ai pas utilisé l'interface web pour gérer les différences de fichiers, je ne me suis pas soucié du fait qu'ils n'affichaient pas le contenu à cet endroit.
Je n'utilise d'ailleurs que très rarement l'interface web. Et je n'utilise aucun bouton Git dans MetaEditor. Je regarde dans Git Bash pour Windows - directement dans le terminal - c'est suffisant et pratique pour moi.
Vous pouvez donc trouver la liste des fichiers "cassés", mais pourquoi ?
Pour connaître la liste des fichiers cassés afin de les réparer. Pour les réparer afin de pouvoir consulter diff.
A quoi sert diff ? [suppression d'une phrase sans importance qui posait des problèmes au traducteur automatique].
Si l'on sait déjà qu'il s'agit de fichiers créés par ME (en encodage UTF-16 LE)
J'ai testé cela il y a quelques mois. L'assistant crée des fichiers UTF-8 (normaux, pas cassés). Même l'assistant MT4 crée des fichiers normaux. Au cours de ces tests, je n'ai jamais réussi à obtenir un fichier "cassé" de l'assistant.
Je vérifie parfois les fichiers avec ce script avant de les valider. Et, comme il s'est avéré, ce n'est pas pour rien - il y a eu des cas où des fichiers normaux ont soudainement changé d'encodage. Peut-être après avoir inséré quelque chose dans le presse-papiers, mais je n'en suis pas sûr. Il est peu probable que le cyrillique ait été présent - j'ai renoncé à l'utiliser, même dans les commentaires, il y a longtemps.
L'alphabet cyrillique n'était guère présent - il y a longtemps que j'ai renoncé à l'utiliser, même dans les commentaires.
Apparemment, je me suis trompé. Je viens d'ajouter ceci au fichier .mq5 avec un encodage UTF-8 :
// Cyrilliqueet après avoir sauvegardé le fichier, l'encodage est devenu "UTF-16 LE BOM".
Il semble que ce soit la faute de MetaEditor. J'ai ajouté des caractères cyrilliques et sauvegardé le fichier en utilisant Notepad++ et l'encodage est resté UTF-8.
Je trouve également étrange d'argumenter en faveur de la nécessité de pouvoir supprimer des branches du dépôt local. Étant donné que le modèle de branchement de Git est sa principale caractéristique et que Git encourage la création, la suppression et la fusion fréquentes de branches.
Je suis donc également en faveur de la suppression des branches après leur fusion avec les branches principales. C'est juste la première fois que j'entends dire qu'après la suppression, ils créent une branche pour la nouvelle fiche avec le même nom, et non une nouvelle.
Quel est l'intérêt de regarder diff ?
Oui, c'est une chose très nécessaire. Je l'utilise activement aussi, mais seulement dans VS Code. Et là, bizarrement, il n'y a pas de plantage, même si je regarde les fichiers avec un "mauvais" encodage.
Je n'ai jamais rencontré une telle chose. C'est assez inattendu. Peut-être que la rupture des fichiers normaux était due à l'utilisation simultanée de différentes versions de ME pour travailler avec les mêmes fichiers ? Je ne sais pas...
J'ai regardé l'historique des modifications, et les fichiers ajoutés il y a deux mois ont effectivement déjà un encodage UTF-8, et les fichiers ajoutés il y a trois mois sont toujours UTF-16 LE. Apparemment, il y a eu un passage à l'encodage UTF-8 à peu près à ce moment-là.
Je crois que je me suis trompé. Je viens de l'ajouter au fichier .mq5 avec l'encodage UTF-8 :
et après avoir sauvegardé le fichier, l'encodage est devenu "UTF-16 LE BOM".
Il semble que ce soit la faute de MetaEditor. J'ai ajouté des caractères cyrilliques et sauvegardé le fichier en utilisant Notepad++ et l'encodage est resté UTF-8.
Je confirme qu'après avoir ajouté des lettres russes et sauvegardé le fichier, l'encodage passe d'UTF-8 à UTF-16 LE. Si toutes les lettres russes sont supprimées et sauvegardées, l'encodage reste UTF-16 LE.
Il semble que ce soit la faute de MetaEditor.
Voici une preuve que l'on peut rendre compatibles UTF-8, Cyrillique et Git :
https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea
Il suffit de demander à MetaEditor de ne pas changer l'encodage du fichier.