Discussione sull’articolo "Introduzione a MQL5 Algo Forge" - 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
Un "fork" e un "clone" non sono la stessa cosa. Non confondere i due concetti
Capisco perfettamente!
Il motivo per cui voglio usare "clone" e non "fork" è che non È perché voglio "seguire" il lavoro originale e tutti i futuri aggiornamenti che si verificheranno, ed essere avvisato quando ci sono nuovi "commit" che devo "tirare". Questa è la ragione dell'esistenza della funzionalità chiamata "clone".
Spiegato questo, MetaQuotes non dovrebbe promuovere un "fork" e poi inserirlo con "clone". Dovrebbe essere un "fork" e poi un "pull", non un "clone". Stanno confondendo le diverse funzionalità.
EDIT: Se MetaQuotes insiste nell'implementare una soluzione Git "storpiata", chiamandola "funzionalità", finirà per essere peggiore del precedente metodo SVN.
Intendevo dire che quando un clone git di un repository viene creato sulla macchina locale, non c'è alcuna differenza (nella composizione dei file e nella cronologia dei commit) tra la clonazione dal repository originale e la clonazione da un nuovo fork.
La documentazione di Git descrive come è possibile ottenere gli aggiornamenti dal repository originale in un clone del proprio fork di quel repository.Questo richiede almeno una conoscenza di base del repository tramite un'interfaccia a riga di comando. Quindi, di fatto, la possibilità di aggiornare un clone locale del codice esiste. Tuttavia, per creare questo clone locale usando solo MetaEditor, è necessario creare un fork del repository originale nel proprio profilo utente. Solo dopo la creazione del fork, il suo nome apparirà nell'elenco dei progetti condivisi in MetaEditor.
In generale, non mi piace molto questo approccio. Dopo tutto, se non abbiamo intenzione di fare modifiche al repository di qualcun altro, non abbiamo bisogno di un fork, un clone del repository originale è sufficiente. Un fork in questo caso è una voce "extra" nell'elenco dei nostri repository. Per quanto ne so, creiamo un fork quando abbiamo intenzione di apportare attivamente modifiche al codice prelevato dal repository originale e non ci aspettiamo che queste modifiche vengano trasferite dal nostro fork al repository originale (anche se c'è questa possibilità tramite Pull Request).
Mettendoci al posto degli sviluppatori di MetaQuotes, potremmo, per esempio, aggiungere una cartella separata con un nome fisso, come "Altri progetti condivisi", per i cloni di altri repository. Ma questa opzione ha i suoi svantaggi, quindi probabilmente è ancora peggiore della soluzione attuale. Non riesco a pensare subito a un'opzione migliore. Forse le funzionalità di MetaEditor saranno estese in futuro e ci verrà presentata qualche altra soluzione.
Vorrei testare la funzionalità dell'aggiornamento. Per questo ho creato un fork del tuo repository FMIC, l'ho aggiunto alla mia watch list e ai miei preferiti. Aspetterò il tuo prossimo commit per vedere come posso scoprirlo in modo da provare ad aggiornare il fork.
Come test, ho aggiunto una descrizione della pubblicazione Heikin Ashi, come file Markdown README, e l'ho inserita nel repository.
Per favore, vedete se vi viene notificata la modifica e se siete in grado di aggiornare il fork.
MetaEditor non è in grado di eseguire il commit di file immagine JPG o di qualsiasi altro tipo di file che considera "irriconoscibile", ma sono in grado di eseguirlo utilizzando un client Git esterno.
PS! AlgoForge è basato sul software open source ForgeJo.
Come prova, ho aggiunto una descrizione della pubblicazione Heikin Ashi come file README in formato Markdown e l'ho inserita nel repository.
Verificate se avete ricevuto la notifica di questa modifica e se potete aggiornare il fork.
Ho visto questo nell'interfaccia web del repository:
Cercherò di aggiornare il fork più tardi
Come prova, ho aggiunto una descrizione della pubblicazione Heikin Ashi come file README in formato Markdown e l'ho inserita nel repository.
Verificate se avete ricevuto la notifica di questa modifica e se potete aggiornare il fork.
Innanzitutto, il mio clone locale del fork non ha ancora l'ultimo commit:
Collegare il repository originale, secondo la documentazione di Git:
Vado all'interfaccia web del fork e vedo questo:
Faccio clic sul pulsante "Sync" e poi eseguo un Pull in MetaEditor:
Come si può vedere, tutti i commit erano al sicuro nel fork e poi dopo il Pull nel clone del fork sul mio computer locale.
In questa pagina di documentazione ci sono altri modi per sincronizzare usando i comandi della console, ma non li ho testati, perché tutti i commit sono già sincronizzati.
Più tardi farò altri esperimenti per vedere come si comporterà il comando Commit e Push di MetaEditor per il fork. Mi chiedo se cercherà di inviare le modifiche anche al repository originale.
Innanzitutto, il mio clone locale del fork non ha ancora l'ultimo commit:
Collegare il repository originale, secondo la documentazione di Git:
Vado all'interfaccia web del fork e vedo questo:
Faccio clic sul pulsante "Sync" e poi eseguo un Pull in MetaEditor:
Come potete vedere, tutti i vostri commit erano al sicuro nel fork e poi dopo il Pull nel clone del fork sul mio computer locale.
In questa pagina della documentazione ci sono altri modi per sincronizzare usando i comandi della console, ma non li ho testati, perché tutti i commit sono già sincronizzati.
Tutto questo va bene, ma avete dimostrato il mio punto di vista: un "clone" e una "biforcazione" non sono la stessa cosa, e il metodo adottato da MetaQuotes richiede un intervento supplementare al di fuori di MetaEditor solo per poter sincronizzare il progetto.
Per non parlare del fatto che richiede spazio di archiviazione extra sui server di AlgoForge, per le "forchette", mentre un "clone" non richiede spazio di archiviazione extra né passaggi extra.
Considero le implementazioni di MetaQuotes troppo "difettose" per un uso efficace e continuerò a usare un client Git esterno, o a usare VSCode (che funziona benissimo con AlgoForge senza problemi).
Considero le implementazioni di MetaQuotes troppo "difettose" per un uso efficace e continuerò a utilizzare un client Git esterno, oppure VSCode (che funziona benissimo con AlgoForge senza problemi).
Siamo lieti di darti il benvenuto nella nostra comunità di utenti di client Git esterni!😁
Trovo che l'implementazione di MetaQuotes sia troppo "difettosa" per essere utilizzata in modo efficace e continuerò a usare un client Git esterno o VSCode (che funziona bene con AlgoForge senza problemi).
Sfortunatamente, questo è il caso per ora. Anch'io preferisco usare un client esterno per ora. Ma se si confronta ciò che è stato aggiunto a MetaEditor negli ultimi 5 mesi, i progressi sono notevoli. È solo che prima non c'erano strumenti per lavorare con il nuovo repository, mentre ora c'è almeno una versione ridotta.