Discussing the article: "Moving to MQL5 Algo Forge (Part 2): Working with Multiple Repositories" - 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
I suggest you in the process of improvement to try to perform a couple of iterations of some primitive branching strategy using only MetaEditor and web interface.
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 is an article that describes points 1 and 2, but somehow it just so happens that point 3 is not in the article (although point 3 is a logical continuation).
Item 3 is missing because I prefer the approach where branches of different features have different names, not always the same (next). With your approach, it's not clear to me why next should be removed at all? It seems similar in meaning to the develop branch in the main/develop bundle, and is used to work on each new feature when adding features sequentially.
After brainstorming for a few days, I managed to find a way to at least fill in the list of "broken" files.
Yes, at one time I also tried a script to clear the common repository of all compiled files, which, as it turned out, quickly turned out to be unnecessary. Since I didn't use the web interface to deal with file differences, it didn't matter to me that they didn't display the content there. So finding out the list of "broken" files is possible, but why? If it is already known that they are all files created by ME (UTF-16 LE encoded), that is all my repository files except for README.md, .gitignore and a couple of others.
Renat, can you tell me if it makes sense to convert all sources to UTF-8 or will ME continue to be oriented 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?
Oh, I just created a new file in ME (New Class), so it was created immediately in UTF-8.
With your approach, it's not clear to me why you would delete the next branch at all?
I always delete a branch immediately after it has been fully merged into a branch of a higher stability level. It's a habit and I'm sure it's a very useful habit.
On a purely technical level, rebuilding a branch often makes quite a tangible difference in the form of a parent commit (parent commit of the next commit). Sometimes this is not critical and only affects the usability of the commit graph, and sometimes you can't do without recreating.
[edit]
In general, I find it strange to argue that it's necessary to be able to remove branches from the local repository. Given that Git's branching model is its killer feature and Git encourages frequent creation, deletion and merging of branches.
Since I didn't use the web interface to deal with file differences, it didn't matter to me that they didn't display the content there.
I very rarely use the web interface either. And I don't use any Git buttons in MetaEditor. I look in Git Bash for Windows - right in the terminal - it's enough and convenient for me.
So you can find out the list of "broken" files, but why?
To know the list of broken files in order to fix them. To fix them in order to be able to look at diff.
What is diff for? [deleted an unimportant sentence that was causing problems for the automatic translator].
If it is already known that these are all files created by ME (in UTF-16 LE encoding)
I tested this a couple of months ago. Wizard creates UTF-8 (normal, not broken files). Even MT4 wizard creates normal files. During those tests, I never once managed to get a "broken" file from wizard.
I sometimes check files with that script before committing. And, as it turned out, not for nothing - there were cases when normal files suddenly changed encoding. Perhaps after inserting something from the clipboard, I don't know for sure. It is unlikely that Cyrillic was there - I gave up using it even in comments a long time ago.
The Cyrillic alphabet was hardly there - I gave up using it even in comments a long time ago.
Apparently, I was mistaken. I just added this to the .mq5 file with UTF-8 encoding:
// Cyrillicand after saving the file encoding changed to "UTF-16 LE BOM".
It seems to be MetaEditor's fault. I added Cyrillic characters and saved the file using Notepad++ and the encoding remained UTF-8.
I also find it strange to argue for the need to be able to remove branches from the local repository. Given that Git's branching model is its killer feature and Git encourages frequent creation, deletion and merging of branches.
So I'm also in favour of deleting branches after they merge with the main branches. It's just the first time I've heard that after deletion, they create a branch for the new fiche with the same name, not a new one.
What is the purpose of watching diff?
Yes, it is a very necessary thing. I actively use it too, but only in VS Code. And there, strangely enough, there are no crashes there, though I look through files with "bad" encoding.
I've never encountered such a thing. It's pretty unexpected, too. Maybe the breakage of normal files was due to simultaneous use of different ME builds to work with the same files? I don't know...
I looked at the commit history, that files added two months ago do indeed already have UTF-8 encoding, and files added three months ago are still UTF-16 LE. Apparently there was a switch to UTF-8 encoding somewhere around that time.
I guess I was wrong. I just added this to the .mq5 file with UTF-8 encoding:
and after saving the file encoding changed to "UTF-16 LE BOM".
It seems to be MetaEditor's fault. I added Cyrillic characters and saved the file using Notepad++ and the encoding remained UTF-8.
I confirm, after adding Russian letters and saving the file the encoding changes from UTF-8 to UTF-16 LE. If all Russian letters are removed and saved, it still remains UTF-16 LE.
It seems to be MetaEditor's fault.
Here is a proof that you can make UTF-8, Cyrillic and Git compatible:
https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea
All you need to do is to ask MetaEditor not to change the file encoding.