Moving to MQL5 Algo Forge (Part 3): Using External Repositories in Your Own Projects

Introduction

In the second part of our transition to MQL5 Algo Forge, we focused on solving one of the important challenges –working with multiple repositories. Using the combination of the Adwizard library project and the Simple Candles Expert Advisor, we encountered and successfully resolved issues mostly related to file inclusion paths and branch merging. We also tried to use MetaEditor tools (where possible) throughout the entire workflow, from creating a separate branch for fixes to merging it via a Pull Request. However, where MetaEditor functionality was not enough, we switched to the MQL5 Algo Forge web interface, an external Git client in Visual Studio Code, or Git console commands. This clearly demonstrated how even in individual development, you can apply Git best practices to maintain order and a clear history of changes within your project.

But that was only one side: using the storage as a "closed" ecosystem where the developer owns all the repositories used. The logical next step, and one of the main reasons for moving to Git, is the ability to fully leverage public repositories from other community members. This is where the true potential of distributed development reveals itself: the ability to easily connect and update third-party code, contribute to its improvement, and assemble complex projects from ready-made, well-tested components. 

In this article, we finally turn to this promising, yet more complex, task: how to practically connect and use libraries from third-party repositories within MQL5 Algo Forge. And not "someday in the future" but right now, without waiting for further development of MetaEditor's repository tools. 

Mapping out the Path

In this article, we will continue working with our Simple Candles project repository, which will serve as an excellent testing ground for experimentation. The existing trading strategy already includes a custom volatility calculation functionally similar to the standard Average True Range (ATR) indicator. However, instead of relying solely on own implementation, we will explore how to improve the code by including specialized, ready-to-use solutions from the community.

To do this, we will turn to the publicly available SmartATR repository, assuming it contains a more advanced and optimized version of the indicator. Our long-term practical goal is to modify the EA so that it can choose between continuing to use the internal calculation or switching to the external SmartATR library algorithm. However, in this article, we will not focus on building a fully functional EA but instead examine the key aspects of working with external repositories.

To achieve this, we need to do the following. Download the SmartATR library code to our local machine and set it up for inclusion in our project. We will cover how to add an external repository into your working environment so that it can later be easily updated when new versions are released. After that, we will apply modifications both to the Simple Candles project and (as it turns out to be necessary) to the SmartATR library code itself. Ideally, we could avoid the last step, but since our case requires it, we will use this as a practical example of how to introduce changes to someone else's repository. Finally, we will verify the integration by testing whether the SmartATR library can be successfully included and compiled as part of our project.

This approach will allow us to carefully walk through the entire process of integrating external code. The experience will be universal: once we have successfully added one library, we will be able to include any other public repository from MQL5 Algo Forge into our projects using the same approach.

Obtaining External Code

At first glance, this shouldn't pose a problem. Any Git repository can be cloned to a local computer using the standard console command:

git clone ...

However, we agreed to follow a specific order: first try working through MetaEditor interface, then the MQL5 Algo Forge web interface, and only if those approaches fail, resort to external tools such as Visual Studio Code or Git console commands.

So the first question is: how do we view someone else's repository in MetaEditor to select it for cloning? The partial answer could be found in the help documentation, but very few users would know where to look right away. We ourselves only came across this page later. Before that, we noticed that the Shared Projects folder in MetaEditor only showed our own repositories. To investigate further, we tried the context menu options available for this folder in MetaEditor's Navigator. 

The New Project option is not the right one here, as it only creates a new repository owned by us. Refresh doesn't t add any external repositories either. The 'Show All Files' option behaves oddly: after running it, duplicate names appeared for our repositories that hadn't yet been cloned locally. Fortunately, pressing Refresh removes these duplicate names. Our last hope was the 'Show All Public Projects' option, it also produced no visible changes.

Unfortunately, this means that for now we cannot rely solely on MetaEditor to clone external repositories. Let's look at a couple of alternative approaches to achieve our goal.

Approach One: Direct Cloning

Let's start with an experiment. If we create an empty folder with any arbitrary name (e.g., TestRepo) inside Shared Projects, it becomes visible in MetaEditor. From there, we can even execute the Clone command from its context menu. However, judging by the logs, MetaEditor then attempts to clone a repository with the same name (TestRepo) from our personal storage – a repository which, of course, doesn't exist:

This confirms that the method won't work for cloning someone else's repository. Let's instead try cloning the SmartATR repository directly into Shared Projects using the 'git clone ...' console command and see what happens.

After cloning, a new SmartATR folder appears in Shared Projects, and it is displayed in MetaEditor's Navigator. More importantly, we can not only view this repository but also work with it as a repository: perform Pull and view the change history (Log) directly from MetaEditor.

Thus, what MetaEditor currently lacks is a context menu option such as 'Clone from...', which would allow the user to specify the URL of a repository from the storage, or alternatively, open a dialog to search and select from all public repositories in MQL5 Algo Forge (similar to the Explore section in the web interface). Another possible improvement could be to display not only personal repositories under Shared Projects but also public repositories that the user has starred in the web interface (Starred Repositories), with the ability to toggle their visibility. But let's not speculate too far about what changes might eventually be introduced in MetaEditor.

For now, returning to our successfully cloned SmartATR repository, we can say the immediate goal has been achieved. The project's source code is now available locally, which means we can use it in our own projects. However, there's a caveat. We can only proceed with the direct usage if SmartATR code requires no modifications, meaning we can use it "out of the box", updating only when new versions are released. Let's see of we can do this.

Checking Functionality

Within the SmartATR project, we received a file with the source code for a MetaTrader 5 indicator, which (according to the description) calculates the Average True Range (ATR) using a more advanced approach. Let's try compiling it… and we immediately encounter an error. 

Regardless of how serious the error is, the important point is this: we cannot use the project without making changes. At this stage, we must decide whether to apply fixes only for our local use or whether to share them and contribute to the original repository. Other developers might also encounter the same issue when trying to use code from this project. So, the second option is more preferable, as it aligns with the philosophy of open-source development.

For now, however, let's assume that we will not be publishing fixes at the moment. First of all, we need to resolve the errors; only then will we have something meaningful to publish. In this case, if we only plan to make local changes to the SmartATR project, we can simply create a new local branch. 

Let's try to do this. The original SmartATR repository contains only a main branch, so we'll create a new develop branch via the context menu of the project folder in MetaEditor. The branch appears in the list of branches shown in MetaEditor. After pressing Push, the logs confirm that the operation was successful. At this point, we might expect that the new branch has been created in the original repository. But checking the MQL5 Algo Forge web interface shows otherwise: nothing has changed.

Next, let's try editing the code and committing changes from MetaEditor. We add comments before each line that caused an error, noting the need for fixes, and commit these changes. The MetaEditor logs indicate that both the commit and the push were successful.

Yet once again, by checking the original repository in the MQL5 Algo Forge web interface, we see that nothing has changed. This is at the very least unusual. Let's check the project in Visual Studio Code. and try to understand what's happening. We open the folder with our SmartATR project clone and see the following:

The latest commit exists, but VS Code suggests we publish the develop branch. This means that the branch does not yet exist in the remote repository, nor does our commit. We try to publish the branch but get an error:

Check the logs to find out the reason:

Our user account does not have write permissions for the original repository. This makes sense. Otherwise, the project could easily devolve into chaos with uncontrolled edits from anyone. This means that we can only make modifications in our local copy. However, these changes cannot be synchronized with the remote and will exist only in our local clone. This is far from ideal. Beyond collaboration options, external repositories perform a very important role – they serve as an store project backups. Giving up that safety net would be unwise.

It's also worth noting that when working exclusively in MetaEditor, there was no indication that something was wrong. According to the MetaEditor logs, everything appeared fine: no errors, and all changes were "successfully" pushed… to a non-existent repository. Hopefully, this issue will be corrected in future builds.

Approach Two: Cloning a Fork

Let's now try a different route. Here too, we'll need to step outside the current capabilities of MetaEditor – this time we will additionally use the MQL5 Algo Forge web interface. For developers who find command-line Git operations challenging, this provides a compromise. In the web interface of MQL5 Algo Forge, we can fork the desired original repository. 

Fork is a fundamental concept in version control systems and collaborative development platforms, including MQL5 Algo Forge. It means the process of creating a complete and independent copy of the original repository within the platform.

When a user forks someone else's repository, the platform creates an exact copy under the user's account. This copy inherits all change history, branches, and files from the source project at the time of forking, but from that moment onward it becomes an autonomous repository. The new owner can freely modify it without affecting the original.

Thus, a fork enables any user to build upon an existing project and develop it along their own path, effectively creating a new branch of evolution for the code. This concept enables the creation of derivative projects and alternative implementations within the open-source ecosystem.

Forks are also the primary means of contributing changes to projects where the user does not have direct write access. The standard workflow is as follows: create a fork, implement and test the required changes in it, and then notify the maintainer of the original repository about the proposed improvements via a Pull Request, which we already covered in Part 2. This is the basis of the decentralized collaborative development model.

Despite their independence, forks maintain a technical link to the source repository. This makes it possible to track changes in the original and synchronize them into your fork, merging new commits from the upstream project into your own.

It's important to distinguish between a fork and a simple clone. Cloning refers to creating a local copy of a repository on a specific computer, while a fork is a complete copy on the platform itself, establishing a new remote repository under another user's ownership.

Therefore, once we fork a repository, it becomes our own repository. It also becomes visible in the Shared Projects list in MetaEditor and available for cloning directly through MetaEditor.

Testing Work with a Fork

Thanks to the kind assistance of Fernando Carreiro, we were able to test this mechanism in practice. We forked his repository FMIC, and at the same time added the original repository to our Watch and Starred lists in the MQL5 Algo Forge web interface.

As expected, the fork appeared in the list of repositories displayed under Shared Projects in MetaEditor:

This allowed us to successfully clone our newly created fork of the FMIC repository to the local computer.

Next, we asked Fernando to commit some changes so that we could test how updates would be reflected in our fork. He added a sample README.md file describing the Heikin Ashi publication and committed it to the repository.

Afterwards, in the web interface we indeed saw a notification about the new changes:

However, these notifications did not yet affect either our fork stored on MQL5 Algo Forge or the local clone on our computer. Let's try to pull Fernando's changes into our repositories. First, we check that the latest changes are indeed missing in our local clone:

The last commit in our local history was dated August 27, 2025, whereas Fernando's changes were made later.

Now, if we visit our fork in the web interface, we see a message that our main branch is three commits behind the original repository:

We also see a Sync button, which should synchronize our main folder with the upstream branch. We then check the history of commits and see three new commits dated September 5, 2025, which were absent before:

In other words, all commits made in the original repository successfully propagated first into our fork on MQL5 Algo Forge, and then into our local clone of that fork.

For those who wish to explore this mechanism in more detail, we recommend consulting the following GitHub documentation sections: 

• Fork a repository
• Configuring a remote repository
• Synchronize

While this documentation isn't written specifically for MQL5 Algo Forge, much of the web interface behaves similarly, and console Git commands are universally applicable regardless of the hosting platform. Provided, of course, that the platform is based on Git.

For example, following the upsteam configuration guidelines, we can set up synchronization so that every Pull/Push operation also updates our fork clone against the original repository:

However, when working exclusively through MetaEditor and the MQL5 Algo Forge web interface, this extra configuration step is not strictly necessary.

Forking SmartATR

Let's now return to the repository we originally planned to use. We'll repeat the same steps – creating a fork via the MQL5 Algo Forge web interface and cloning it locally – for the SmartATR repository.

We begin by searching for the original repository in the Explore section by entering its name:

Since the repository already has several forks created by other users, the search results also display those forks. To fork the true original, we scroll further down the results and open the page for steverosenstock/SmartATR.

There we click the Fork button:

After clicking, we are redirected to the fork creation settings page. Here, we can rename the forked repository (as it will appear in our list of repositories), specify which branches from the original should be included, and edit the repository description if desired:

By default, the fork is created as an exact copy of the original repository. That works perfectly for us, so we simply click "Fork repository".

The fork is successfully created:

Next, we clone this repository to our local computer. Before doing so, we delete the previously cloned original SmartATR folder from the local computer. If MetaEditor was already open, we need to refresh the folder list by selecting Refresh from the Shared Projects context menu. After that, the SmartATR folder appears, and from its context menu we select 'Git Clone': 

The SmartATR project is successfully cloned:

We are now ready to begin making changes.

Making Changes

Since our goal is to introduce fixes that either resolve or at least neutralize a specific error, we begin by creating a new branch whose name clearly reflects this purpose; for example, fixes/news-impact:

We then switch to this branch in the project's context menu by selecting "Git Branches → fixes-news-impact".

Note that although we originally included a slash ("/") in the branch name, the branch was actually created with that character automatically replaced by a hyphen ("-"). This is a limitation imposed by MetaEditor, which only permits Latin letters and hyphens in branch names. Technically, Git itself allows slashes, and through the web interface we can freely create branches containing them. 

Let's test the importance of this restriction. We'll create another branch directly in the MQL5 Algo Forge web interface, this time explicitly including a slash in its name: fixes/cast-warning. From the Branches page, we select New branch, using the main branch as the base:

The branch is successfully created:

However, when attempting to run a Pull in MetaEditor, we are presented with an error message:

Even so, the new branch with the slash in its name does appear in the branch list inside MetaEditor, and switching to it works without further issues:

After making note of this peculiarity, we switch back to the branch fixes-news-impact and introduce the temporary fix that removes the cause of the compilation error:

Once the indicator compiles without errors, we commit our changes through the context menu option 'Git Commit': 

In the commit dialog, we check the list of modified files. The check is simple in this case, as we only changed one file. It is strongly recommended to add a descriptive comment that explains the nature of the fix. After confirming all is correct, we press OK.

Our changes are now committed and pushed to our fork of the SmartATR repository in MQL5 Algo Forge. At this stage, the corrected version of the indicator can already be used locally, with a safe copy also stored in the repository. Optionally, we could submit a Pull Request to the original project author by pressing 'New pull request' in the repository's web interface:

However, it's too early, since our modification simply disables part of the functionality rather than improving the code. For now, we do not create a pull request.

The SmartATR indicator is ready to be integrated into our Simple Candles project.

Integrating the Indicator

Following best practices, we create a new branch in the Simple Candles project repository – article-19436-forge3 – based on the develop branch. To vary our approach, we create this branch using the MQL5 Algo Forge web interface.

To make the branch appear locally, we run 'Git Pull' in MetaEditor and then switch to the new branch article-19436-forge3.

Since our intention is to apply the indicator within the trading strategy, we add it directly to the strategy class implementation in SimpleCandlesStrategy.mqh. Specifically, we introduce a class field to store the indicator handle:

//+------------------------------------------------------------------+
//| Trading strategy using unidirectional candlesticks               |
//+------------------------------------------------------------------+
class CSimpleCandlesStrategy : public CVirtualStrategy {
protected:
   //...

   int               m_iATRHandle;        // SmartATR indicator handle

   //...
};

Next, we call iCustom() in the class constructor, passing the required symbol, timeframe, path to the indicator file, and its parameters:

//+------------------------------------------------------------------+
//| Constructor                                                      |
//+------------------------------------------------------------------+
CSimpleCandlesStrategy::CSimpleCandlesStrategy(string p_params) {
// Read the parameters from the initialization string
   // ...

   if(IsValid()) {
      // Load the SmartATR indicator
      m_iATRHandle = iCustom(
                        m_symbol, m_timeframe,
                        "Shared Projects/SmartATR/SmartATR.ex5",
                        // Indicator parameters
                        m_periodATR,   // Initial ATR period (used for first calculation, adaptively changes)
                        false,         // Enable adaptive period (dynamic lookback)
                        7,             // Minimum ATR period (adaptive mode)
                        28,            // Maximum ATR period (adaptive mode)
                        false,         // Weight True Range by volume
                        false,         // Weight True Range by economic news events (MT5 Calendar)
                        2.0,           // Multiplier: alert if ATR exceeds this factor of average
                        false          // Enable pop-up & sound alerts on high volatility
                     );

      // ...
   }
}

Note the path specified for the indicator. It starts with Shared Projects, then the project folder name SmartATR, followed by the indicator filename SmartATR.ex5. Including the .ex5 extension is optional, but keeping it helps avoid confusion.

There's one important nuance which should be taken into account when working in the Shared Projects folder. This refers to both your own and forked projects. All compiled executables are not placed directly in the repository folder. This is because the Shared Projects folder is located in the terminal data root folder: MQL5/Shared Projects. On the one hand, this is good since the version control system will not try to suggest indexing executable files. On the other hand, it can be a bit confusing at first: Where do we find the compiled Expert Advisor and indicator files?

They are actually created in their respective standard folders, such as MQL5/Experts for EAs or MQL5/Indicators for indicators. Within those, a Shared Projects subdirectory is automatically created. So, the compiled files are created right in those subfolders. This means that compiling a file from MQL5/Shared Projects/SmartATR.mq5 will produce the executable at MQL5/Indicators/Shared Projects/SmartATR/SmartATR.ex5.

Accordingly, the iCustom() call must reference the indicator path relative to MQL5/Indicators.

Finally, we compile the advisor file SimpleCandles.mq5 and run it in the strategy tester. The logs show the following:

Thus, the SmartATR indicator has been successfully loaded, initialized, and is ready for use. At this point, we are only demonstrating its integration. We might add actual use within the strategy logic later. We commit these changes and push them to the MQL5 Algo Forge repository.

Conclusion

This article demonstrates how adopting MQL5 Algo Forge enables a fundamentally more flexible workflow for developers. Previously, we only examined self-contained repositories, but here we have successfully integrated an external library from a third-party repository into our project.

The key moment was the correct workflow based on forking – creating a personal copy of an external repository that allows full modification while staying synchronized with the upstream project. The successful integration of SmartATR into Simple Candles supports this approach – from locating and forking the repository, to modifying and applying its code in a live trading strategy.

Importantly, this process was achieved entirely with current MetaEditor capabilities, without waiting for future updates. The limitations of MetaEditor (such as lack of direct access to third-party repositories and restricted branch naming) are easily overcome by complementing it with the MQL5 Algo Forge web interface and, if necessary, standard Git console commands. In short, the system is already viable for practical use, and the remaining interface shortcomings are inconveniences rather than blockers.

However, let's not stop there. We will continue using repositories to separate projects and our sharing experiences gained along the way.

Thank you for your attention! See you soon!