Discussing the article: "Moving to MQL5 Algo Forge (Part 2): Working with Multiple Repositories"
https://www.mql5.com/en/articles/17698
Before merging , we can once again visually review all the changes in the convenient interface of the MQL5 Algo Forge repository. During such a purposeful check, we sometimes manage to notice things that escaped during commits: unnecessary comments, accidentally added files, suboptimal changes. In essence, it's a form of self-discipline. Besides, getting used to the correct processes develops the habit of working in this way (creating a separate branch, code-review, ...).
Let me guess why the author did not demonstrate"viewing changes in the convenient interface of the MQL5 Algo Forge repository". Because the author can't do it, because diff doesn't work. The reason diff doesn't work is that Git considers source code files to be binary. You can see it even on the screenshot from the article:
https://www.mql5.com/en/articles/17698
This completes the merge process: thearticle-17698-forge2 branch is mergedinto the develop branchand deleted:
It is removed only from the server, but not from MetaEditor (local repository). Either the author accidentally stopped at the most interesting point, or it's another problem they chose to keep silent about.
[It's like writing an article about a sports car that forgot to add brakes. Describe how wonderful it goes 300 km/hour, but leave out the fact that you can only stop if you hit a wall or a good tree.Let me guess why the author has not demonstrated"viewing changes in the convenient interface of the MQL5 Algo Forge repository". Because the author can't do it because diff doesn't work. The reason diff doesn't work is that Git considers source code files to be binary. You can even see it on the screenshot from the article:
I can't do everything at once, unfortunately. This is not an attempt to hide the problem. I was almost sure that it can be easily fixed, so I didn't emphasise it. Now I did an experiment - I converted one repository file to UTF-8. In ME it opens and compiles without any difference from when it was in UTF-16 LE. In the web interface, you can now see the differences normally. In general, it's not Git that considers source code files to be binary, but more like the Forgejo-based web interface is not designed to handle text files in UTF-16 LE encoding, which MetaEditor used by default.
But diff in MetaEditor is.... Apparently, it can only use UTF-16 LE - Russian letters of a file in UTF-8 are not displayed correctly and the whole file is considered changed because of differences at the end of all lines:
In the process of writing the article I didn't use diff in ME, because... I simply got used to using it while ME was adding Git support and had to keep VS Code running in parallel for all operations with the repository. That's why it didn't make it into the article.
I'm trying to suggest alternative ways for a reason, because so far ME still has problems with repositories. But at the same time I want to believe that they will be fixed in time. In the meantime, let's use what we have.
It is removed only from the server, but not from MetaEditor (local repository). Either the author accidentally stopped at the most interesting place, or this is another problem that they preferred to keep silent about.
Thanks for the remark. Indeed, when deleting a branch from a remote repository, it should not be automatically deleted from all clones of this repository on local computers. It should be deleted separately in local repositories. This is true of all Git-based repositories, so it's not an Algo Forge problem.
[edit] It's like writing an article about a sports car that forgot to add brakes. Describe how wonderful it drives at 300 km/h, but leave out the fact that you can only stop if you hit a wall or a nice tree.
Oh, that's for sure! The drive is extraordinary ) Although, to be honest, I would prefer not to stumble like this on every corner. It's good to be going. And where its brakes are not enough, we will try to use external brakes.
In general,it is not Git that considers source files binary, but more likely that the Forgejo-based web interface is not designed to handle text files in UTF-16 LE encoding, which is the default encoding used by MetaEditor.
No, Git itself considers binary files with the encoding that MetaEditor sometimes saves them in. Neither forgejo nor its web interface has anything to do with this. The proof is on your repository in Git Bash for Windows:
No, Git itself considers binary files with the encoding that MetaEditor sometimes saves them in. Neither forgejo nor its web interface has anything to do with this. The proof is on your repository in Git Bash for Windows:
However, despite this VS Code even in UTF-16 LE encoding calmly shows all the differences. Well, Git itself calls them binary.
The main thing we found out is that after converting to UTF-8 the problem is solved in Git console and web-interface (but there is another problem in Diff ME):
No, Git itself considers binary files with the encoding that MetaEditor sometimes saves them in. Neither forgejo nor its web interface has anything to do with this. The proof is on your repository in Git Bash for Windows:
After racking my brain for a few days, I managed to find a way to at least fill in the list of "broken" files. The method is based on the fact that the command
git ls-files --format='%(eolinfo:index) %(path)'
displays "-text" for them:
But that command looks only at index (modified and untracked files are ignored). I didn't bother with the eolinfo peculiarities and decided to stupidly add all files to the index of the new repository. As a result, I made a tool that allows you to check for "broken" files before they are bricked: https: //forge.mql5.io/boyvlad/mql-check-binary-surprises.
Logic of use: before committing, copy all project files (except .git folder and gitignore file) to a separate folder and run the script (link to which I gave above) in it. The script will list the broken files, having first initialised a new git repository and added all files to index. The script will first make sure that the .git folder and gitignore files are not present - protection against accidentally launching in the working directory instead of a copy of it.
Example usage:
We will fix it step by step, including working in the editor
In the process of improvement, I suggest you try to perform a couple of iterations of some primitive branching strategy using only MetaEditor and the web interface.
- Create branch next, make a couple of commits there
- Pour next into main, delete next
- Created next again with a new parent commit, made a couple of commits.
- ...
Point 3 is currently impossible without using external tools. So the fact that point 2 can be done through the site doesn't make it any easier, because it's a dead end.
I haven't said anything new in this discussion - I already reported all this a couple of months ago. Now there's an article coming out that covers points 1 and 2, but it just so happens that point 3 is not in the article (although point 3 is a logical extension).
Git without branding is like soup without broth
We will fix step by step, including work in the editor
Renat, can you tell me if it makes sense to convert all sources to UTF-8 or will ME continue to focus only on UTF-16 LE? I think somewhere in the branches of new builds or somewhere else it was mentioned about transition to UTF-8, but maybe it seemed?
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Check out the new article: Moving to MQL5 Algo Forge (Part 2): Working with Multiple Repositories.
In the first article, we began transitioning from the built-in SVN-based MQL5 Storage in MetaEditor to a more flexible and modern solution based on the Git version control system: MQL5 Algo Forge. The main reason for this step was the need to fully leverage repository branches while working on multiple projects or on different functionalities within a single project.
The transition started with the creation of a new repository in MQL5 Algo Forge and the setup of a local development environment using Visual Studio Code, along with the necessary MQL5 and Git extensions and supporting tools. We then added a .gitignore file to the repository to exclude standard and temporary files from version control. All existing projects were uploaded into a dedicated archive branch, designated as an archival storage of all previously written code. The main branch was left empty and prepared for organizing new project branches. In this way, we laid the foundation for distributing different project codes across separate branches of the repository.
Author: Yuriy Bykov