Discussão do artigo "Migrando para o MQL5 Algo Forge (Parte 2): Trabalhando com múltiplos repositórios"
https://www.mql5.com/pt/articles/17698
Antes da mesclagem , podemos mais uma vez revisar visualmente todas as alterações na conveniente interface do repositório MQL5 Algo Forge. Durante essa verificação intencional, às vezes conseguimos perceber coisas que escaparam durante os commits: comentários desnecessários, arquivos adicionados acidentalmente, alterações abaixo do ideal. Em essência, é uma forma de autodisciplina. Além disso, acostumar-se aos processos corretos desenvolve o hábito de trabalhar dessa forma (criar uma ramificação separada, revisão de código, ...).
Deixe-me adivinhar por que o autor não demonstrou"a visualização das alterações na interface conveniente do repositório MQL5 Algo Forge". Porque o autor não pode fazer isso, porque o diff não funciona. A razão pela qual o diff não funciona é que o Git considera os arquivos de código-fonte como binários. Você pode ver isso até mesmo na captura de tela do artigo:
https://www.mql5.com/pt/articles/17698
Isso conclui o processo de mesclagem: a ramificação article-17698-forge2é mescladana ramificação develop e excluída:
Ele é removido apenas do servidor, mas não do MetaEditor (repositório local). Ou o autor parou acidentalmente no ponto mais interessante ou se trata de outro problema sobre o qual ele preferiu manter silêncio.
[É como escrever um artigo sobre um carro esportivo que se esqueceu de adicionar freios. Descreva como é maravilhoso andar a 300 km/hora, mas deixe de fora o fato de que você só pode parar se bater em uma parede ou em uma boa árvore.Deixe-me adivinhar por que o autor não demonstrou"a visualização das alterações na interface conveniente do repositório MQL5 Algo Forge". Porque o autor não pode fazer isso porque o diff não funciona. A razão pela qual o diff não funciona é que o Git considera os arquivos de código-fonte como binários. Você pode ver isso até mesmo na captura de tela do artigo:
Infelizmente, não é possível fazer tudo de uma vez. Essa não é uma tentativa de ocultar o problema. Eu tinha quase certeza de que ele poderia ser facilmente corrigido, por isso não o enfatizei. Agora fiz um experimento: converti um arquivo do repositório para UTF-8. No ME, ele abre e compila sem nenhuma diferença em relação a quando estava em UTF-16 LE. Na interface da Web, agora você pode ver as diferenças normalmente. Em geral,não é o Git que considera os arquivos de código-fonte como binários, mas a interface da Web baseada no Forgejo não foi projetada para lidar com arquivos de texto na codificação UTF-16 LE, que o MetaEditor usava por padrão.
Mas o diff no MetaEditor é.... Aparentemente, ele só pode usar UTF-16 LE - as letras russas de um arquivo em UTF-8 não são exibidas corretamente e o arquivo inteiro é considerado alterado por causa das diferenças no final de todas as linhas:
No processo de escrever o artigo, não usei o diff no ME, porque... Eu simplesmente me acostumei a usá-lo enquanto o ME estava adicionando suporte ao Git e tinha que manter o VS Code em execução em paralelo para todas as operações com o repositório. É por isso que ele não foi incluído no artigo.
Estou tentando sugerir formas alternativas por um motivo, porque até agora o ME ainda tem problemas com repositórios. Mas, ao mesmo tempo, quero acreditar que eles serão corrigidos com o tempo. Enquanto isso, vamos usar o que temos.
Ele é removido apenas do servidor, mas não do MetaEditor (repositório local). Ou o autor parou acidentalmente no local mais interessante, ou esse é outro problema sobre o qual preferiu manter silêncio.
Obrigado pela observação. De fato, ao excluir um branch de um repositório remoto, ele não deve ser excluído automaticamente de todos os clones desse repositório nos computadores locais. Ele deve ser excluído separadamente nos repositórios locais. Isso é verdade para todos os repositórios baseados em Git, portanto, não é um problema do Algo Forge.
[É como escrever um artigo sobre um carro esportivo que se esqueceu de adicionar freios. Descreva como é maravilhoso dirigir a 300 km/h, mas deixe de fora o fato de que você só pode parar se bater em uma parede ou em uma bela árvore.
Ah, isso é certo! A direção é extraordinária ) Embora, para ser sincero, eu preferisse não tropeçar assim em todas as curvas. É bom estar indo. E quando os freios não forem suficientes, tentaremos usar os freios externos.
Em geral,não é o Git que considera os arquivos de origem binários, mas é mais provável que a interface da Web baseada no Forgejo não tenha sido projetada para lidar com arquivos de texto na codificação UTF-16 LE, que é a codificação padrão usada pelo MetaEditor.
Não, o próprio Git considera os arquivos binários com a codificação em que o MetaEditor às vezes os salva. Nem o forgejo nem sua interface da Web têm algo a ver com isso. A prova está em seu repositório no Git Bash para Windows:
Não, o próprio Git considera os arquivos binários com a codificação em que o MetaEditor às vezes os salva. Nem o forgejo nem sua interface da Web têm algo a ver com isso. A prova está em seu repositório no Git Bash para Windows:
No entanto, apesar disso, o VS Code, mesmo na codificação UTF-16 LE, mostra calmamente todas as diferenças. Bem, o próprio Git as chama de binárias.
A principal coisa que descobrimos é que, após a conversão para UTF-8, o problema é resolvido no console do Git e na interface da Web (mas há outro problema no Diff ME):
Não, o próprio Git considera os arquivos binários com a codificação em que o MetaEditor às vezes os salva. Nem o forgejo nem sua interface da Web têm algo a ver com isso. A prova está em seu repositório no Git Bash para Windows:
Depois de pensar por alguns dias, consegui encontrar uma maneira de, pelo menos, preencher a lista de arquivos "quebrados". O método se baseia no fato de que o comando
git ls-files --format='%(eolinfo:index) %(path)'
exibe "-text" para eles:
Mas esse comando analisa apenas o índice (arquivos modificados e não rastreados são ignorados). Não me preocupei com as peculiaridades do eolinfo e decidi adicionar estupidamente todos os arquivos ao índice do novo repositório. Como resultado, criei uma ferramenta que permite verificar se há arquivos "quebrados" antes que eles sejam bloqueados: https: //forge.mql5.io/boyvlad/mql-check-binary-surprises.
Lógica de uso: antes de fazer o commit, copie todos os arquivos do projeto (exceto a pasta .git e o arquivo gitignore) para uma pasta separada e execute o script (link para o qual forneci acima) nela. O script listará os arquivos corrompidos, tendo primeiro inicializado um novo repositório git e adicionado todos os arquivos ao índice. O script primeiro se certificará de que a pasta .git e os arquivos gitignore não estejam presentes - uma proteção contra a inicialização acidental no diretório de trabalho em vez de uma cópia dele.
Exemplo de uso:
Vamos corrigi-lo passo a passo, incluindo o trabalho no editor
No processo de aprimoramento, sugiro que você tente executar algumas iterações de alguma estratégia de ramificação primitiva usando apenas o MetaEditor e a interface da Web.
- Crie a ramificação next, faça alguns commits nela
- Despeje o próximo no principal, exclua o próximo
- Criei o próximo novamente com um novo commit principal, fiz alguns commits.
- ...
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 está sendo publicado um artigo que aborda os pontos 1 e 2, mas acontece que o ponto 3 não está no artigo (embora o ponto 3 seja uma extensão lógica).
Git sem branding é como sopa sem caldo
Faremos a correção passo a passo, incluindo o trabalho no editor
Renat, você pode me dizer se faz sentido converter todos os códigos-fonte para UTF-8 ou se o ME continuará a se concentrar apenas no 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?
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Você concorda com a política do site e com os termos de uso
Novo artigo Migrando para o MQL5 Algo Forge (Parte 2): Trabalhando com múltiplos repositórios foi publicado:
No primeiro artigo iniciamos a transição do uso do MQL5 Storage — o repositório SVN integrado ao MetaEditor — para uma solução mais flexível e moderna baseada no sistema de controle de versões Git: MQL5 Algo Forge. A principal razão para essa mudança foi a necessidade de usar plenamente diferentes branches do repositório ao trabalhar em vários projetos ou em funcionalidades distintas dentro de um mesmo projeto.
A transição começou com a criação de um novo repositório no MQL5 Algo Forge e a configuração do ambiente local de desenvolvimento utilizando o Visual Studio Code, as extensões necessárias para trabalhar com MQL5 e Git, além da instalação das ferramentas apropriadas. Em seguida, adicionamos ao repositório o arquivo .gitignore para excluir do rastreamento arquivos padrão e temporários. Todos os projetos existentes foram carregados em uma branch separada chamada archive, que assumiu o papel de repositório de arquivamento de todo o código já existente. A branch principal main foi deixada vazia e preparada para a criação de novas branches específicas para cada projeto. Dessa forma, estabelecemos a base necessária para a futura organização do código de diferentes projetos em diferentes branches do repositório.
Autor: Yuriy Bykov