Destaques do Git 2.48

O projeto Git de código aberto acaba de lançar o Git 2.48 com recursos e correções de bugs de mais de 93 colaboradores, 35 deles novos. A última vez que falamos sobre as últimas novidades do Git foi quando o 2.47 foi lançado.

Para comemorar este lançamento mais recente, aqui está uma visão do GitHub sobre alguns dos recursos e mudanças mais interessantes introduzidos desde a última vez.

SHA-1s mais rápidos sem comprometer a segurança

Quando publicamos nossa cobertura do lançamento 2.47 do Git, deixamos de mencionar um punhado de mudanças de desempenho que foram feitas bem no final do ciclo. Como esta versão contém uma correção de bug relacionada a essas mudanças, achamos que agora era um momento tão bom quanto qualquer outro para discutir essas mudanças. Você provavelmente sabe que o Git usa hashes SHA-1 por padrão para identificar objetos dentro do seu repositório. (Nós cobrimos a capacidade do Git de usar SHA-256 como sua função de hash primária, mas para este detalhe vamos focar no Git em seu modo SHA-1).

O que você pode não saber é que o Git usa hashes SHA-1 internamente em alguns pontos também. O mais notável para nossos propósitos é que o formato do pacote inclui um SHA-1 final que armazena a soma de verificação dos bytes precedentes. O Git usa esses dados para validar que o conteúdo de um pacote corresponde ao que foi anunciado e não foi corrompido em trânsito.

Por padrão, o Git usa uma implementação de detecção de colisão do SHA-1, fortalecendo-o contra ataques SHA-1 comuns como SHAttered e Shambles . (O GitHub também usa a implementação de detecção de colisão do SHA-1). Embora a implementação de detecção de colisão do SHA-1 proteja o Git contra ataques de colisão, ele faz isso ao custo de alguns ciclos extras de CPU para procurar os sinais reveladores desses ataques durante a soma de verificação.

Na maioria dos casos, o impacto no desempenho é insignificante, e o benefício supera o pequeno custo de desempenho. Mas ao calcular a soma de verificação de um pacote grande (como ao clonar um repositório grande), o custo aumenta. Por exemplo, usamos o Callgrind e medimos que o Git gasta cerca de 78% de sua CPU calculando uma soma de verificação durante um clone simulado de torvalds/linux.

Felizmente, o trailing checksum é uma medida de integridade de dados, não de segurança. Para nossos propósitos, isso significa que podemos usar com segurança uma implementação mais rápida e sem detecção de colisões do SHA-1, especificamente ao calcular trailing checksums (mas em nenhum outro lugar) sem comprometer a segurança. O Git 2.47 introduziu novas opções de tempo de construção para especificar uma implementação de função hash separada usada especificamente ao calcular trailing checksums. O GitHub usou essa opção e, como resultado, mediu uma melhoria de desempenho de 10-13% no atendimento de buscas/clones em todos os repositórios.

Você pode testar a capacidade do Git de selecionar implementações alternativas de funções hash compilando com make OPENSSL_SHA1_UNSAFE=1, ou outras _UNSAFE variantes.

Trazendo –remerge-diff para range-diff

Leitores regulares desta série sem dúvida se lembrarão da nossa cobertura do comando range-diff do Git (introduzido no Git 2.19) e da opção mais nova –remerge-diff (lançada no Git 2.36). Caso você seja um leitor iniciante, ou nenhuma dessas opções lhe pareça familiar, não se preocupe; aqui vai uma breve atualização.

O comando do Git range-diff permite que você compare duas sequências de commits, incluindo mudanças em sua ordem, mensagens de commit e as mudanças reais de conteúdo que elas introduzem. Isso pode ser útil ao comparar uma sequência de commits que foram rebaseados (potencialmente ajustando a ordem e as mudanças dentro dos patches ao longo do caminho), com a aparência daquele conjunto de commits antes do rebase.

A opção do Git –remerge-diff diz a git show, git log, ou vários comandos relacionados a diff para visualizar as diferenças entre onde o Git teria parado com a mesclagem e o que está registrado na mesclagem. Isso pode ser útil ao lidar com conflitos de mesclagem, já que –remerge-diff a visualização mostrará a diferença entre os conflitos e sua resolução, mostrando como um determinado conflito de mesclagem foi tratado.

No Git 2.48, esses dois recursos se encontram pela primeira vez e range-diff agora aceitam uma –remerge-diff opção para que, se alguém refizer uma sequência de commits –rebase-merges e potencialmente precisar fazer algumas alterações, as alterações nas confirmações de mesclagem também possam ser revisadas como parte do range-diff. Como efeito colateral deste trabalho, um bug antigo –remerge-diff também foi corrigido, o que em particular permitirá git log –remerge-diff que seja usado junto com opções que alteram a ordem de passagem de confirmação (como –reverse).

Testes sem vazamento de memória no Git

Começando lá atrás no Git 2.34 , o projeto Git tem se concentrado em reduzir vazamentos de memória com o objetivo de, em última análise, tornar o Git livre de vazamentos. Como o Git é uma ferramenta de linha de comando, cada execução normalmente dura apenas um breve período de tempo, após o qual o kernel liberará qualquer memória alocada ao Git que o próprio Git não liberou. Por causa disso, vazamentos de memória no Git não representam um problema prático significativo para o uso diário.

Mas, ter vazamentos de memória no Git dificulta a conversão de grande parte dos internos do Git em uma biblioteca chamável, onde ter vazamentos de memória seria um problema significativo. Para resolver isso, houve um esforço concentrado ao longo de muitos anos para reduzir o número de vazamentos de memória na base de código do Git, com o objetivo final de eliminá-los completamente.

Depois de muito esforço para esse fim, o Git agora pode executar seu conjunto de testes com sucesso com a verificação de vazamentos habilitada. Como resultado final satisfatório, grande parte da infraestrutura de teste sobre a qual falamos na versão 2.34 foi removida, resultando em uma infraestrutura de teste mais simples. Tornar a memória do Git livre de vazamentos representa um progresso significativo para ser capaz de converter componentes internos do Git em uma biblioteca que pode ser acionada.

Apresentando o Meson no Git

O projeto Git usa o GNU Make como o principal meio de compilar o Git, o que significa que se você puder obter uma cópia do código-fonte do Git, executar make deve ser tudo o que você precisa para obter um binário Git funcional (desde que você tenha as dependências necessárias, etc.). Há algumas exceções, a saber, que o Git tem algum suporte para Autoconf e CMake, embora eles não sejam tão atualizados quanto o Makefile.

Mas, à medida que o projeto Git se aproxima de seu 20º aniversário no final deste ano, ele Makefile está começando a mostrar sua idade. Houve mais de 2.000 commits para o Makefile, resultando em um script de construção com quase 4.000 linhas de comprimento. Nesta versão, o projeto Git tem suporte para um novo sistema de construção, Meson, como uma alternativa à construção com GNU Make. Embora o suporte para Meson ainda não seja tão robusto quanto a construção com Make, Meson oferece um punhado de vantagens sobre Make. Meson é mais fácil de usar do que Make, tornando o projeto mais acessível para novatos ou colaboradores que não têm experiência significativa trabalhando com Make. Meson também tem amplo suporte IDE e suporta construções fora da árvore e multiplataforma, que são ambos ativos significativos para o projeto Git.

O Git manterá o suporte para Make e CMake, além do Meson, no futuro próximo, e manterá o suporte para Autoconf por um pouco mais de tempo. Mas se você estiver curioso para experimentar o mais novo sistema de build do Git, você pode executar meson setup build && ninja -C build em uma cópia nova do Git 2.48 ou mais recente.

• Conforme o projeto Git cresceu ao longo dos anos, ele acumulou uma série de recursos e modos que, embora razoáveis quando introduzidos pela primeira vez, desde então se tornaram obsoletos ou substituídos e agora estão obsoletos. No Git 2.48, o projeto Git começou a coletar esses recursos agora obsoletos em uma lista armazenada em Documentation/BreakingChanges.txt. Este documento permite que o projeto Git discuta a descontinuação de certos recursos e coleta as descontinuações previstas do projeto em um único lugar. Do outro lado da equação, ele permite que os usuários vejam se podem ser afetados por uma descontinuação futura e compartilhem seu caso de uso de um recurso específico com o projeto. Confira a lista para ver se há algo lá que você pode perder e para ter uma ideia antecipada de como pode ser um eventual lançamento do Git 3.0!
• Se você já fez scripts em torno das referências do seu repositório, provavelmente está familiarizado com for-each-ref o comando do Git. Caso não esteja, for-each-ref é uma ferramenta flexível que permite listar referências no seu repositório, aplicar especificadores de formatação personalizados a elas e muito mais. No Git 2.44, falamos sobre algumas melhorias de desempenho que permitiram git for-each-ref uma execução significativamente mais rápida ao combinar filtragem de referência e formatação no mesmo caminho de código, eliminando a necessidade de armazenar e classificar os resultados em certas condições. O Git 2.48 estende essas mudanças ao nos permitir tirar vantagem das mesmas otimizações mesmo quando solicitado a produzir as referências em ordem classificada (sob certas condições). Desde que essas condições sejam atendidas, você pode produzir rapidamente um pequeno número de referências, mesmo independentemente –sort=refname de quantas referências seu repositório realmente tem. Enquanto estamos no tópico de referências, o subsistema reftable recebeu mais atenção nesta versão. A implementação reftable do Git foi atualizada para evitar dependências explícitas em algumas das APIs de conveniência do Git, fazendo mais progresso em ser capaz de compilar o código reftable sem libgit.a. A implementação reftable também foi atualizada para lidar graciosamente com falhas de alocação de memória em vez de sair do processo imediatamente. Por último, mas não menos importante, o código reftable foi atualizado para ser capaz de reutilizar iteradores de referência, resultando em criação de referência mais rápida e menor uso de memória ao usar reftables. Para mais informações sobre tabelas de referência, confira nossa cobertura anterior sobre tabelas de referência.
• Quando você clona de um repositório remoto, o branch padrão que o repositório remoto usa é refletido em refs/remotes/origin/HEAD locally 2. Em versões anteriores do Git, buscas e pulls subsequentes não atualizavam essa referência simbólica. Com o Git 2.48, se o remoto tiver um branch padrão, mas refs/remotes/origin/HEAD estiver faltando localmente, então um fetch o atualizará. Se quiser ir um passo além, você pode definir remote.origin.followRemoteHead a configuração como warn ou always; se fizer isso, quando refs/remotes/origin/HEAD já existir, mas não corresponder à ramificação padrão no lado remoto, quando você executá-lo, git fetch ele o avisará sobre a alteração ou apenas atualizará automaticamente refs/remote/origin/HEAD para o valor apropriado, dependendo da configuração usada. Para aqueles que não estão familiarizados com clones parciais ou querem aprender mais sobre seus componentes internos, você pode ler o guia “Aprenda a usar clones parciais e clones superficiais”.

O resto do iceberg

Essa é apenas uma amostra das mudanças da versão mais recente. Para mais, confira as notas de versão para 2.48 ou qualquer versão anterior no repositório Git.

Fonte: GitHub Brasil.

LEIA TMBÉM:

• Certificação GitHub Foundations Grátis: Destaque-se no Mercado
• GitHub Copilot – Hacks, Tutoriais e Novidades
• Git e Github – Como gerar chave SSH no Git?
• Como aprender aprendizado de máquina com repositórios GitHub?
• Coleção de E-Books sobre Git e GitHub grátis
• Livros de Inteligência Artificial com JavaScript e TypeScript em Português