Discussing the article: "Getting Started with MQL5 Algo Forge" - page 2
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
No! A "fork" and a "clone" are not the same thing. Please do not confuse the two concepts
I understand perfectly!
The reason I want to use "clone" and not "fork", is not because I want to modify or work on it with my own derivative work. It is because I want to "follow" the original work and any future updates that will occur, and be notified when there are new "commits" that I then need to "pull". That is the reason for the existence of the functionality called "clone".
That explained, MetaQuotes should not be promoting a "fork" and then pulling it in with "clone". It should be a "fork" and then a "pull", not "clone". They are mixing up the different functionalities.
EDIT: If MetaQuotes insists on implementing a "crippled" Git solution, and calling it a "feature", then it will end up worse than the previous SVN method.
What I meant was that when a git clone of a repository is made on the local machine, there is no difference (in file composition and commit history) between cloning from the original repository or cloning from a fresh fork.
The Git documentation describes how you can get updates from the original repository into a clone of your fork of that repository.This requires at least basic repository skills via a command line interface. So, in fact, the ability to update a local clone of code is actually there. However, to create this local clone using only MetaEditor, you must create a fork of the original repository in your user profile. Only after the fork is created, its name will appear in the list of Shared Projects in MetaEditor.
In general, I don't really like this approach. After all, if we don't plan to make edits to someone else's repository, we don't need a fork, a clone of the original repository is enough. A fork in this case is an additional "extra" item in the list of our repositories. As I understand it, we create a fork when we plan to actively make changes to the code taken from the original repository and we don't expect that these changes will be transferred from our fork to the original repository (although there is such a possibility via Pull Request).
Putting ourselves in the place of MetaQuotes developers, we could, for example, add a separate folder with a fixed name, like "Other Shared Projects", for clones of other repositories. But this option has its own disadvantages, so it is probably even worse than the current solution. I can't think of any better options right away. Perhaps MetaEditor functionality will be extended in the future and we will be presented with some other solution.
I would like to test the functionality of the update. That's why I made a fork of your FMIC repository, added it to my watch list and favourites. I'll wait for your next commit to see how I can find out about it so I can try to update the fork.
As a test, a added a description of the Heikin Ashi publication, as a Markdown README file, and committed it to the repository.
Please, see if you are notified of the change and if you are able to update the fork.
MetaEditor is also unable to commit JPG image files or any other file type that it deems "unrecognisable", but I am able to commit them using an external Git client.
PS! AlgoForge is based on the open source ForgeJo software.
As a test, I added a description of the Heikin Ashi publication as a README file in Markdown format and committed it to the repository.
Please check if you have received notification of this change and if you can update the fork.
Saw this in the repository web interface:
I will try to update the fork later
As a test, I added a description of the Heikin Ashi publication as a README file in Markdown format and committed it to the repository.
Please check if you have received notification of this change and if you can update the fork.
First up, my local fork clone doesn't have the latest commit yet:
Connecting the original repository, according to the Git documentation:
I go to the web interface of the fork and see this:
I click the "Sync" button and then do a Pull in MetaEditor:
As you can see, all your commits were safely in the fork and then after Pull in the clone of the fork on my local computer.
On this documentation page there are other ways to synchronise using console commands, but I haven't tested them, as all commits are already synchronised.
I'll experiment more later to see how the Commit and Push command in MetaEditor will behave for the fork. I wonder if it will try to send edits to the original repository as well.
First up, my local fork clone doesn't have the latest commit yet:
Connecting the original repository, according to the Git documentation:
I go to the web interface of the fork and see this:
I click the "Sync" button and then do a Pull in MetaEditor:
As you can see, all your commits were safely in the fork and then after Pull in the clone of the fork on my local computer.
On this page of the documentation there are other ways to synchronise using console commands, but I haven't tested them, because all commits are already synchronised.
This is all fine, but you have proven my point that a "Clone" and a "Fork" are not the same, and the method that MetaQuotes has adopted requires extra intervention outside of MetaEditor just to be able to synchronise the project.
Not to mention that it requires extra storage space on the AlgoForge servers, for "forks", while a "clone" requires no extra storage nor extra steps.
I consider the MetaQuotes implementations too "flawed" for effective use and will continue to use an external Git client, or using VSCode (which works just fine with AlgoForge without issues).
I consider the MetaQuotes implementations too "flawed" for effective use and will continue to use an external Git client, or using VSCode (which works just fine with AlgoForge without issues).
We are glad to welcome you to our community of external Git clients users!😁
I find the MetaQuotes implementation too "flawed" to use effectively and will continue to use an external Git client or VSCode (which works fine with AlgoForge with no issues).
Unfortunately, this is indeed the case for now. I too prefer to use an external client for now. But if you compare what has been added to MetaEditor in the last 5 months, it's a noticeable progress. It's just that before there were no tools for working with the new repository at all, and now there is at least such a reduced version.