Discussione sull’articolo "Passaggio a MQL5 Algo Forge (parte 2): Lavorare con Più Repository" - pagina 2
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Vi suggerisco, nel processo di miglioramento, di provare a eseguire un paio di iterazioni di una strategia di ramificazione primitiva utilizzando solo MetaEditor e l'interfaccia web.
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 c'è un articolo che descrive i punti 1 e 2, ma si dà il caso che il punto 3 non sia presente nell'articolo (sebbene il punto 3 sia una continuazione logica).
Il punto 3 manca perché preferisco l'approccio in cui i rami di diverse caratteristiche hanno nomi diversi, non sempre gli stessi (successivo). Con il vostro approccio, non mi è chiaro perché next dovrebbe essere rimosso? Il suo significato sembra simile a quello del ramo develop nel bundle main/develop e viene usato per lavorare su ogni nuova funzionalità quando si aggiungono funzionalità in sequenza.
Dopo qualche giorno di brainstorming, sono riuscito a trovare un modo per riempire almeno l'elenco dei file "rotti".
Sì, a un certo punto ho provato anche uno script per cancellare il repository comune da tutti i file compilati, che, come si è scoperto, si è rapidamente rivelato inutile. Poiché non usavo l'interfaccia web per gestire le differenze tra i file, non mi importava che non visualizzassero il contenuto. Quindi è possibile scoprire l'elenco dei file "rotti", ma perché? Se è già noto che sono tutti file creati da ME (codificati UTF-16 LE), sono tutti i file del mio repository tranne README.md, .gitignore e un paio di altri.
Renat, puoi dirmi se ha senso convertire tutte le fonti in UTF-8 o ME continuerà ad essere orientato solo su UTF-16 LE? Penso 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?
Oh, ho appena creato un nuovo file in ME (New Class), quindi è stato creato immediatamente in UTF-8.
Con il tuo approccio, non mi è chiaro perché dovresti cancellare il ramo successivo?
Io cancello sempre un ramo subito dopo che è stato completamente fuso in un ramo con un livello di stabilità superiore. È un'abitudine e sono sicuro che sia molto utile.
A livello puramente tecnico, la ricostruzione di un ramo spesso fa una differenza abbastanza tangibile sotto forma di un commit genitore (commit genitore del commit successivo). A volte questo non è critico e influisce solo sull'usabilità del grafico dei commit, mentre a volte non si può fare a meno di ricreare.
[edit]
In generale, trovo strano sostenere che sia necessario poter rimuovere i rami dal repository locale. Dato che il modello di ramificazione di Git è la sua caratteristica principale e Git incoraggia la creazione, la cancellazione e l'unione frequente di rami.
Poiché non utilizzo l'interfaccia web per gestire le differenze tra i file, non mi importava che non visualizzassero il contenuto.
Anch'io uso molto raramente l'interfaccia web. E non uso alcun pulsante Git in MetaEditor. Guardo in Git Bash per Windows, direttamente nel terminale: per me è sufficiente e conveniente.
Quindi è possibile trovare l'elenco dei file "rotti", ma perché?
Conoscere l'elenco dei file non funzionanti per poterli riparare. Sistemarli per poter guardare il diff.
A cosa serve diff? [cancellata una frase non importante che creava problemi al traduttore automatico].
Se è già noto che questi sono tutti file creati da ME (in codifica UTF-16 LE)
L'ho testato un paio di mesi fa. La procedura guidata crea file UTF-8 (normali, non rotti). Anche la procedura guidata MT4 crea file normali. Durante questi test, non sono mai riuscito a ottenere un file "rotto" dalla procedura guidata.
A volte controllo i file con questo script prima di eseguire il commit. E, come si è scoperto, non per niente: ci sono stati casi in cui i file normali hanno improvvisamente cambiato codifica. Forse dopo aver inserito qualcosa dagli appunti, non lo so con certezza. È improbabile che ci fosse il cirillico: ho smesso di usarlo anche nei commenti molto tempo fa.
L'alfabeto cirillico non c'era quasi - ho rinunciato a usarlo anche nei commenti molto tempo fa.
A quanto pare, mi sono sbagliato. Ho appena aggiunto questo al file .mq5 con la codifica UTF-8:
// Cirillicoe dopo aver salvato il file la codifica è cambiata in "UTF-16 LE BOM".
Sembra che sia colpa di MetaEditor. Ho aggiunto i caratteri cirillici e salvato il file usando Notepad++ e la codifica è rimasta UTF-8.
Trovo anche strano sostenere la necessità di poter rimuovere i rami dal repository locale. Dato che il modello di ramificazione di Git è la sua caratteristica principale e Git incoraggia la creazione, la cancellazione e l'unione frequente di rami.
Quindi sono anche favorevole alla cancellazione dei rami dopo la loro fusione con i rami principali. È solo la prima volta che sento dire che dopo la cancellazione si crea un ramo per la nuova scheda con lo stesso nome, non uno nuovo.
Qual è lo scopo di guardare diff?
Sì, è una cosa molto necessaria. Anch'io lo uso attivamente, ma solo in VS Code. E lì, stranamente, non ci sono crash, anche se guardo i file con una codifica "cattiva".
Non ho mai riscontrato una cosa del genere. È anche piuttosto inaspettato. Forse la rottura dei file normali era dovuta all'uso simultaneo di diverse build di ME per lavorare con gli stessi file? Non lo so...
Ho dato un'occhiata alla cronologia dei commit: i file aggiunti due mesi fa hanno effettivamente già la codifica UTF-8, mentre i file aggiunti tre mesi fa sono ancora UTF-16 LE. Apparentemente c'è stato un passaggio alla codifica UTF-8 in quel periodo.
Credo di essermi sbagliato. Ho appena aggiunto questo al file .mq5 con la codifica UTF-8:
e dopo aver salvato il file la codifica è cambiata in "UTF-16 LE BOM".
Sembra che sia colpa di MetaEditor. Ho aggiunto i caratteri cirillici e salvato il file con Notepad++ e la codifica è rimasta UTF-8.
Confermo che dopo aver aggiunto le lettere russe e salvato il file la codifica passa da UTF-8 a UTF-16 LE. Se tutte le lettere russe vengono rimosse e salvate, il file rimane UTF-16 LE.
Sembra essere colpa di MetaEditor.
Ecco una prova che consente di rendere compatibili UTF-8, cirillico e Git:
https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea
Tutto quello che si deve fare è chiedere a MetaEditor di non cambiare la codifica del file.