Discussão do artigo "Migrando para o MQL5 Algo Forge (Parte 2): Trabalhando com múltiplos repositórios" - página 2
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Sugiro que, no processo de aprimoramento, você tente executar algumas iterações de alguma estratégia de ramificação primitiva usando apenas o MetaEditor e a interface da Web.
Atualmente, o ponto 3 é impossível sem o uso de ferramentas externas. Portanto, o fato de o ponto 2 poder ser feito por meio do site não o torna mais fácil, porque é um beco sem saída.
Eu não disse nada de novo nesta discussão - já relatei tudo isso há alguns meses. Agora há um artigo que descreve os pontos 1 e 2, mas, de alguma forma, acontece que o ponto 3 não está no artigo (embora o ponto 3 seja uma continuação lógica).
O item 3 está faltando porque prefiro a abordagem em que as ramificações de diferentes recursos têm nomes diferentes, nem sempre os mesmos (a seguir). Com sua abordagem, não está claro para mim por que next deveria ser removido? Ele parece ter um significado semelhante ao da ramificação develop no pacote main/develop, e é usado para trabalhar em cada novo recurso ao adicionar recursos sequencialmente.
Após alguns dias de brainstorming, consegui encontrar uma maneira de, pelo menos, preencher a lista de arquivos "quebrados".
Sim, em um determinado momento, também tentei usar um script para limpar o repositório comum de todos os arquivos compilados, o que, como se viu, rapidamente se mostrou desnecessário. Como eu não usava a interface da Web para lidar com diferenças de arquivos, não me importava que eles não exibissem o conteúdo lá. Portanto, é possível descobrir a lista de arquivos "quebrados", mas por quê? Se já se sabe que todos eles são arquivos criados pelo ME (codificados em UTF-16 LE), são todos os arquivos do meu repositório, exceto README.md, .gitignore e alguns outros.
Renat, você pode me dizer se faz sentido converter todos os códigos-fonte para UTF-8 ou se o ME continuará a ser orientado somente para UTF-16 LE? Acho que em algum lugar nas ramificações de novas compilações ou em outro lugar foi mencionado sobre a transição para UTF-8, mas talvez tenha parecido?
Ah, acabei de criar um novo arquivo no ME (New Class), então ele foi criado imediatamente em UTF-8.
Com sua abordagem, não está claro para mim por que você excluiria o próximo branch?
Eu sempre excluo uma ramificação imediatamente após ela ter sido totalmente mesclada em uma ramificação de um nível de estabilidade mais alto. É um hábito e tenho certeza de que é um hábito muito útil.
Em um nível puramente técnico, a reconstrução de uma ramificação geralmente faz uma diferença bastante tangível na forma de um commit pai (commit pai do próximo commit). Às vezes, isso não é crítico e afeta apenas a usabilidade do gráfico de commits e, às vezes, não é possível fazer isso sem recriar.
[editar]
Em geral, acho estranho argumentar que é necessário ser capaz de remover ramificações do repositório local. Dado que o modelo de ramificação do Git é seu recurso principal e o Git incentiva a criação, exclusão e mesclagem frequentes de ramificações.
Como eu não usava a interface da Web para lidar com diferenças de arquivos, não me importava que eles não exibissem o conteúdo lá.
Eu também raramente uso a interface da Web. E não uso nenhum botão do Git no MetaEditor. Eu procuro no Git Bash para Windows - diretamente no terminal - é suficiente e conveniente para mim.
Então você pode descobrir a lista de arquivos "quebrados", mas por quê?
Para saber a lista de arquivos quebrados a fim de corrigi-los. Para corrigi-los a fim de poder dar uma olhada no diff.
Para que serve o diff? [excluiu uma frase sem importância que estava causando problemas para o tradutor automático].
Se já se sabe que todos esses arquivos são criados pelo ME (na codificação UTF-16 LE)
Testei isso há alguns meses. O assistente cria arquivos UTF-8 (normais, não quebrados). Até mesmo o assistente do MT4 cria arquivos normais. Durante esses testes, nunca consegui obter um arquivo "quebrado" do assistente.
Às vezes, verifico os arquivos com esse script antes de fazer o commit. E, como se viu, não foi por acaso - houve casos em que os arquivos normais mudaram repentinamente de codificação. Talvez depois de inserir algo da área de transferência, mas não sei ao certo. É improvável que o cirílico estivesse lá - eu desisti de usá-lo até mesmo em comentários há muito tempo.
O alfabeto cirílico quase não existia - eu desisti de usá-lo até mesmo em comentários há muito tempo.
Aparentemente, eu estava enganado. Acabei de adicionar isso ao arquivo .mq5 com codificação UTF-8:
// Cirílicoe depois de salvar o arquivo, a codificação mudou para "UTF-16 LE BOM".
Parece que a culpa é do MetaEditor. Adicionei caracteres cirílicos e salvei o arquivo usando o Notepad++ e a codificação permaneceu UTF-8.
Também acho estranho argumentar sobre a necessidade de poder remover ramificações do repositório local. Considerando que o modelo de ramificação do Git é seu recurso principal e que o Git incentiva a criação, a exclusão e a mesclagem frequentes de ramificações.
Portanto, também sou a favor da exclusão de ramificações depois que elas se fundem com as ramificações principais. É a primeira vez que ouço dizer que, após a exclusão, eles criam uma ramificação para a nova ficha com o mesmo nome, e não uma nova.
Qual é a finalidade de observar o diff?
Sim, é algo muito necessário. Eu também o uso ativamente, mas somente no VS Code. E lá, por incrível que pareça, não há falhas, embora eu verifique os arquivos com codificação "ruim".
Nunca encontrei algo assim. Isso também é bastante inesperado. Talvez a quebra dos arquivos normais tenha ocorrido devido ao uso simultâneo de diferentes compilações do ME para trabalhar com os mesmos arquivos? Não sei...
Dei uma olhada no histórico de confirmações e vi que os arquivos adicionados há dois meses já têm codificação UTF-8, e os arquivos adicionados há três meses ainda são UTF-16 LE. Aparentemente, houve uma mudança para a codificação UTF-8 em algum momento daquela época.
Acho que eu estava errado. Acabei de adicionar isso ao arquivo .mq5 com codificação UTF-8:
e depois de salvar o arquivo, a codificação mudou para "UTF-16 LE BOM".
Parece ser culpa do MetaEditor. Adicionei caracteres cirílicos e salvei o arquivo usando o Notepad++ e a codificação permaneceu UTF-8.
Confirmo que, após adicionar letras russas e salvar o arquivo, a codificação muda de UTF-8 para UTF-16 LE. Se todas as letras russas forem removidas e salvas, o arquivo continuará sendo UTF-16 LE.
Parece ser culpa do MetaEditor.
Aqui está uma prova de que você pode tornar o UTF-8, o cirílico e o Git compatíveis:
https://forge.mql5.io/junk/utf8-cyrillic-test/commit/e87d37b02e88d44305dea0f7f6630c6173471aea
Tudo o que você precisa fazer é pedir ao MetaEditor para não alterar a codificação do arquivo.