Discussione sull’articolo "Passaggio a MQL5 Algo Forge (parte 2): Lavorare con Più Repository"
https://www.mql5.com/it/articles/17698
Prima dell'unione , possiamo ancora una volta rivedere visivamente tutte le modifiche nella comoda interfaccia del repository MQL5 Algo Forge. Durante questo controllo mirato, a volte riusciamo a notare cose che sono sfuggite durante i commit: commenti inutili, file aggiunti per sbaglio, modifiche non ottimali. In sostanza, è una forma di autodisciplina. Inoltre, abituarsi ai processi corretti sviluppa l'abitudine a lavorare in questo modo (creazione di un ramo separato, code-review, ...).
Mi spiego perché l'autore non ha dimostrato di"visualizzare le modifiche nella comoda interfaccia del repository MQL5 Algo Forge". Perché l'autore non può farlo, perché diff non funziona. Il motivo per cui diff non funziona è che Git considera i file di codice sorgente come binari. Lo si può vedere anche nella schermata dell'articolo:
https://www.mql5.com/it/articles/17698
Questo completa il processo di fusione: il ramo article-17698-forge2viene unitoal ramo develop e cancellato:
Viene rimosso solo dal server, ma non da MetaEditor (repository locale). O l'autore si è accidentalmente fermato al punto più interessante, oppure si tratta di un altro problema che ha scelto di tacere.
[È come scrivere un articolo su un'auto sportiva che ha dimenticato di aggiungere i freni. Descrivete quanto sia bella la velocità di 300 km/h, ma tralasciate il fatto che potete fermarvi solo se andate a sbattere contro un muro o un albero.Lasciatemi indovinare perché l'autore non ha dimostrato"la visualizzazione delle modifiche nella comoda interfaccia del repository MQL5 Algo Forge". Perché l'autore non può farlo perché diff non funziona. Il motivo per cui diff non funziona è che Git considera i file di codice sorgente come binari. Lo si può vedere anche nella schermata dell'articolo:
Purtroppo non si può fare tutto in una volta. Questo non è un tentativo di nascondere il problema. Ero quasi certo che fosse facilmente risolvibile, quindi non l'ho sottolineato. Ora ho fatto un esperimento: ho convertito un file di repository in UTF-8. In ME si apre e compila senza alcuna differenza rispetto a quando era in UTF-16 LE. Nell'interfaccia web, ora è possibile vedere normalmente le differenze. In generale,non è Git che considera i file di codice sorgente come binari, ma più che altro l'interfaccia web basata su Forgejo non è progettata per gestire i file di testo in codifica UTF-16 LE, che MetaEditor utilizzava per impostazione predefinita.
Ma diff in MetaEditor è.... A quanto pare, può utilizzare solo UTF-16 LE - le lettere russe di un file in UTF-8 non vengono visualizzate correttamente e l'intero file viene considerato modificato a causa delle differenze alla fine di tutte le righe:
Durante la stesura dell'articolo non ho usato diff in ME, perché... Mi sono semplicemente abituato a usarlo mentre ME stava aggiungendo il supporto Git e dovevo tenere VS Code in esecuzione in parallelo per tutte le operazioni con il repository. Ecco perché non è stato inserito nell'articolo.
Sto cercando di suggerire modi alternativi per un motivo, perché finora ME ha ancora problemi con i repository. Ma allo stesso tempo voglio credere che verranno risolti col tempo. Nel frattempo, usiamo quello che abbiamo.
Viene rimosso solo dal server, ma non da MetaEditor (repository locale). O l'autore si è accidentalmente fermato nel punto più interessante, oppure si tratta di un altro problema che ha preferito tacere.
Grazie per l'osservazione. In effetti, quando si cancella un ramo da un repository remoto, non dovrebbe essere automaticamente cancellato da tutti i cloni di questo repository sui computer locali. Dovrebbe essere cancellato separatamente nei repository locali. Questo vale per tutti i repository basati su Git, quindi non è un problema di Algo Forge.
[È come scrivere un articolo su un'auto sportiva che ha dimenticato di aggiungere i freni. Descrivi quanto sia meravigliosa a 300 km/h, ma ometti il fatto che puoi fermarti solo se vai a sbattere contro un muro o un bell'albero.
Oh, questo è certo! La guida è straordinaria) Anche se, a dire il vero, preferirei non inciampare così a ogni curva. È bello andare. E dove i suoi freni non sono sufficienti, cercheremo di usare freni esterni.
In generale,non è Git a considerare binari i file sorgente, ma più probabilmente l'interfaccia web di Forgejo non è progettata per gestire i file di testo con la codifica UTF-16 LE, che è la codifica predefinita utilizzata da MetaEditor.
No, Git stesso considera i file binari con la codifica in cui MetaEditor a volte li salva. Né forgejo né la sua interfaccia web hanno nulla a che fare con questo. La prova è nel vostro repository in Git Bash per Windows:
No, Git stesso considera i file binari con la codifica in cui MetaEditor a volte li salva. Né forgejo né la sua interfaccia web hanno nulla a che fare con questo. La prova è nel vostro repository in Git Bash per Windows:
Tuttavia, nonostante questo VS Code anche nella codifica UTF-16 LE mostra tranquillamente tutte le differenze. Ebbene, Git stesso le chiama "binarie".
La cosa principale che abbiamo scoperto è che dopo la conversione in UTF-8 il problema è risolto nella console e nell'interfaccia web di Git (ma c'è un altro problema in Diff ME):
No, Git stesso considera i file binari con la codifica in cui MetaEditor a volte li salva. Né forgejo né la sua interfaccia web hanno nulla a che fare con questo. La prova è nel vostro repository in Git Bash per Windows:
Dopo essermi scervellato per qualche giorno, sono riuscito a trovare un modo per riempire almeno l'elenco dei file "rotti". Il metodo si basa sul fatto che il comando
git ls-files --format='%(eolinfo:index) %(path)'
visualizza "-testo" per loro:
Ma questo comando guarda solo l'indice (i file modificati e non tracciati vengono ignorati). Non mi sono preoccupato delle peculiarità di eolinfo e ho deciso di aggiungere stupidamente tutti i file all'indice del nuovo repository. Di conseguenza, ho creato uno strumento che permette di verificare la presenza di file "rotti" prima che vengano bloccati: https: //forge.mql5.io/boyvlad/mql-check-binary-surprises.
Logica d'uso: prima di eseguire il commit, copiare tutti i file del progetto (tranne la cartella .git e il file gitignore) in una cartella separata ed eseguire lo script (di cui ho fornito il link sopra) al suo interno. Lo script elencherà i file interrotti, avendo prima inizializzato un nuovo repository git e aggiunto tutti i file all'indice. Lo script si assicurerà innanzitutto che la cartella .git e i file gitignore non siano presenti: una protezione contro il lancio accidentale nella directory di lavoro invece che in una sua copia.
Esempio di utilizzo:
Lo risolveremo passo dopo passo, anche lavorando nell'editor.
Nel processo di miglioramento, vi suggerisco di provare a eseguire un paio di iterazioni di una strategia di ramificazione primitiva usando solo MetaEditor e l'interfaccia web.
- Creare il ramo next, fare un paio di commit lì
- Versare next in main, cancellare next
- Creare di nuovo next con un nuovo commit genitore, fare un paio di commit.
- ...
Il punto 3 è attualmente impossibile senza utilizzare strumenti esterni. Quindi il fatto che il punto 2 possa essere fatto attraverso il sito non lo rende più facile, perché è un vicolo cieco.
Non ho detto nulla di nuovo in questa discussione - ho già riportato tutto questo un paio di mesi fa. Ora sta per uscire un articolo che copre i punti 1 e 2, ma si dà il caso che il punto 3 non sia presente nell'articolo (anche se il punto 3 è un'estensione logica).
Git senza branding è come una zuppa senza brodo
Sistemeremo passo dopo passo, compreso il lavoro nell'editor.
Renat, puoi dirmi se ha senso convertire tutti i sorgenti in UTF-8 o ME continuerà a concentrarsi solo su UTF-16 LE? Credo che da qualche parte nei rami delle nuove build o da qualche altra parte sia stato menzionato il passaggio a UTF-8, ma forse sembrava?
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Accetti la politica del sito e le condizioni d’uso
Il nuovo articolo Passaggio a MQL5 Algo Forge (parte 2): Lavorare con Più Repository è stato pubblicato:
Nel primo articolo, abbiamo iniziato la transizione dal sistema di archiviazione MQL5 integrato in MetaEditor, basato su SVN, a una soluzione più flessibile e moderna, basata sul sistema di controllo delle versioni Git: MQL5 Algo Forge. La ragione principale di questo passo è stata la necessità di sfruttare appieno i rami del repository mentre si lavora su più progetti o su diverse funzionalità all'interno di un singolo progetto.
La transizione è iniziata con la creazione di un nuovo repository in MQL5 Algo Forge e la configurazione di un ambiente di sviluppo locale utilizzando Visual Studio Code, insieme alle necessarie estensioni MQL5 e Git e agli strumenti di supporto. Abbiamo quindi aggiunto un file .gitignore al repository per escludere i file standard e temporanei dal controllo della versione. Tutti i progetti esistenti sono stati caricati in un ramo di archivio dedicato, designato come archivio di tutto il codice scritto in precedenza. Il ramo main è stato lasciato vuoto e preparato per l'organizzazione di nuovi rami di progetto. In questo modo, abbiamo gettato le basi per la distribuzione di diversi codici di progetto in rami separati del repository.
Autore: Yuriy Bykov