Discusión sobre el artículo "Cambiamos a MQL5 Algo Forge (Parte 2): Trabajando con varios repositorios"
https://www.mql5.com/es/articles/17698
Antes de fusionar , una vez más podemos revisar visualmente todos los cambios en la cómoda interfaz del repositorio MQL5 Algo Forge. Durante esta revisión, a veces conseguimos darnos cuenta de cosas que se escaparon durante los commits: comentarios innecesarios, archivos añadidos accidentalmente, cambios subóptimos. En esencia, es una forma de autodisciplina. Además, acostumbrarse a los procesos correctos desarrolla el hábito de trabajar de esta manera (creación de una rama separada, revisión del código, ...).
Déjame adivinar por qué el autor no demostró"ver los cambios en la cómoda interfaz del repositorio MQL5 Algo Forge". Porque el autor no puede hacerlo, porque diff no funciona. diff no funciona porque Git considera que los archivos de código fuente son binarios. Se puede ver incluso en la captura de pantalla del artículo:
https://www.mql5.com/es/articles/17698
Esto completa el proceso de fusión: la rama article-17698-forge2se fusionacon la rama develop y se elimina:
Se elimina sólo del servidor, pero no del MetaEditor (repositorio local). O el autor se detuvo accidentalmente en el punto más interesante, o se trata de otro problema sobre el que decidió guardar silencio.
[Es como escribir un artículo sobre un coche deportivo al que se le han olvidado los frenos. Describes lo maravilloso que es ir a 300 km/h, pero omites el hecho de que sólo puedes frenar si chocas contra un muro o un buen árbol.Déjame adivinar por qué el autor no ha demostrado"ver los cambios en la cómoda interfaz del repositorio MQL5 Algo Forge". Porque el autor no puede hacerlo porque diff no funciona. La razón por la que diff no funciona es que Git considera que los archivos de código fuente son binarios. Se puede ver incluso en la captura de pantalla del artículo:
No se puede hacer todo a la vez, por desgracia. Esto no es un intento de ocultar el problema. Estaba casi seguro de que se puede arreglar fácilmente, así que no hice hincapié en ello. Ahora he hecho un experimento - he convertido un fichero del repositorio a UTF-8. En ME se abre y compila sin ninguna diferencia de cuando estaba en UTF-16 LE. En la interfaz web, ahora se pueden ver las diferencias normalmente. En general,no es que Git considere que los archivos de código fuente sean binarios, sino que la interfaz web basada en Forgejo no está diseñada para manejar archivos de texto en codificación UTF-16 LE, que MetaEditor usaba por defecto.
Pero diff en MetaEditor es.... Aparentemente, sólo puede utilizar UTF-16 LE - las letras rusas de un archivo en UTF-8 no se muestran correctamente y todo el archivo se considera cambiado debido a las diferencias al final de todas las líneas:
En el proceso de escribir el artículo no usé diff en ME, porque... Simplemente me acostumbré a usarlo mientras ME añadía soporte para Git y tenía que mantener VS Code ejecutándose en paralelo para todas las operaciones con el repositorio. Por eso no entró en el artículo.
Estoy tratando de sugerir formas alternativas por una razón, porque hasta ahora ME todavía tiene problemas con los repositorios. Pero al mismo tiempo quiero creer que se arreglarán con el tiempo. Mientras tanto, usemos lo que tenemos.
Sólo se elimina del servidor, pero no del MetaEditor (repositorio local). O el autor se detuvo accidentalmente en el lugar más interesante, o se trata de otro problema sobre el que prefirió guardar silencio.
Gracias por el comentario. Efectivamente, al borrar una rama de un repositorio remoto, no debería borrarse automáticamente de todos los clones de este repositorio en los ordenadores locales. Debería borrarse por separado en los repositorios locales. Esto es cierto para todos los repositorios basados en Git, así que no es un problema de Algo Forge.
[Es como escribir un artículo sobre un coche deportivo al que se le olvidó poner los frenos. Describe lo maravilloso que conduce a 300 km/h, pero omite el hecho de que sólo puede parar si choca contra un muro o un bonito árbol.
Oh, ¡eso seguro! La conducción es extraordinaria ) Aunque, para ser sincero, preferiría no tropezar así en cada curva. Es bueno estar en marcha. Y donde sus frenos no sean suficientes, intentaremos usar frenos externos.
En general,no es Git el que considera binarios los archivos fuente, sino más bien que la interfaz web basada en Forgejo no está diseñada para manejar archivos de texto en codificación UTF-16 LE, que es la codificación por defecto utilizada por MetaEditor.
No, el propio Git considera los archivos binarios con la codificación con la que a veces los guarda MetaEditor. Ni forgejo ni su interfaz web tienen nada que ver con esto. La prueba está en tu repositorio en Git Bash para Windows:
No, el propio Git considera los ficheros binarios con la codificación con la que a veces los guarda MetaEditor. Ni forgejo ni su interfaz web tienen nada que ver con esto. La prueba está en tu repositorio en Git Bash para Windows:
Sin embargo, a pesar de esto VS Code incluso en codificación UTF-16 LE muestra tranquilamente todas las diferencias. Bueno, el propio Git las llama binarias.
Lo principal que descubrimos es que después de convertir a UTF-8 el problema se resuelve en la consola de Git y en la interfaz web (pero hay otro problema en Diff ME):
No, el propio Git considera los ficheros binarios con la codificación con la que a veces los guarda MetaEditor. Ni forgejo ni su interfaz web tienen nada que ver con esto. La prueba está en tu repositorio en Git Bash para Windows:
Después de devanarme los sesos durante unos días, he conseguido encontrar una forma de, al menos, rellenar la lista de archivos "rotos". El método se basa en que el comando
git ls-files --format='%(eolinfo:index) %(path)'
muestra "-text" para ellos:
Pero ese comando sólo mira el índice (los archivos modificados y sin seguimiento se ignoran). No me molesté con las peculiaridades de eolinfo y decidí estúpidamente añadir todos los ficheros al índice del nuevo repositorio. Como resultado, hice una herramienta que permite comprobar si hay ficheros "rotos" antes de que se brickeen: https: //forge.mql5.io/boyvlad/mql-check-binary-surprises.
Lógica de uso: antes de hacer el commit, copia todos los archivos del proyecto (excepto la carpeta .git y el archivo gitignore) a una carpeta separada y ejecuta el script (cuyo enlace he dado más arriba) en ella. El script listará los archivos rotos, habiendo primero inicializado un nuevo repositorio git y añadido todos los archivos al índice. El script se asegurará primero de que la carpeta .git y los archivos gitignore no están presentes - protección contra el lanzamiento accidental en el directorio de trabajo en lugar de una copia del mismo.
Ejemplo de uso:
Lo arreglaremos paso a paso, incluyendo el trabajo en el editor
En el proceso de mejora, te sugiero que intentes realizar un par de iteraciones de alguna estrategia de ramificación primitiva utilizando sólo MetaEditor y la interfaz web.
- Crear rama next, hacer un par de commits allí
- Verter next en main, borrar next
- Crear next de nuevo con un nuevo commit padre, hacer un par de commits
- ...
El punto 3 es actualmente imposible sin utilizar herramientas externas. Así que el hecho de que el punto 2 se pueda hacer a través del sitio no lo hace más fácil, porque es un callejón sin salida.
No he dicho nada nuevo en esta discusión - ya informé de todo esto hace un par de meses. Ahora va a salir un artículo que cubre los puntos 1 y 2, pero da la casualidad de que el punto 3 no está en el artículo (aunque el punto 3 es una extensión lógica).
Git sin branding es como sopa sin caldo
Lo arreglaremos paso a paso, incluyendo el trabajo en el editor
Renat, ¿puedes decirme si tiene sentido convertir todas las fuentes a UTF-8 o ME seguirá centrándose sólo en UTF-16 LE? Creo que en algún lugar de las ramas de nuevas construcciones o en algún otro lugar se mencionó acerca de la transición a UTF-8, pero tal vez parecía?
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Artículo publicado Cambiamos a MQL5 Algo Forge (Parte 2): Trabajando con varios repositorios:
En el primer artículo, comenzamos la transición desde el uso de MQL5 Storage (el almacenamiento SVN incorporado en el MetaEditor) a una solución más flexible y moderna basada en el sistema de control de versiones Git: MQL5 Algo Forge. La razón principal de este paso fue el deseo de usar plenamente diferentes ramas del repositorio mientras se trabaja en diferentes proyectos o funcionalidades dentro de un mismo proyecto.
La transición comenzó con la creación de un nuevo repositorio en MQL5 Algo Forge y la configuración de un entorno de desarrollo local usando Visual Studio Code, las extensiones pertinentes para trabajar con MQL5 y Git, así como la instalación de las herramientas necesarias. A continuación, añadimos un archivo .gitignore al repositorio creado para excluir los archivos estándar y temporales del seguimiento. Todos los proyectos actuales se cargaron en una rama archive independiente, a la que se asignó la función de repositorio de archivo de todo el código existente. La rama principal main se dejó vacía y se preparó para la organización de nuevas ramas de proyectos. De esta forma, se sentaron todas las bases necesarias para la posterior distribución de código de distintos proyectos a distintas ramas del repositorio.
Autor: Yuriy Bykov