Lançamento do sistema de controle de versões Git 2.39

Após dois meses de desenvolvimento, foi lançada a versão 2.39 do sistema de controle de versões distribuído Git. O Git é um dos sistemas de gerenciamento de versões mais populares, confiáveis e de alto desempenho, oferecendo ferramentas flexíveis para desenvolvimento não linear, baseadas em ramificações e fusões de branches. Para garantir a integridade do histórico e a resistência a mudanças 'retroativas', é utilizada a hash implícita de toda a história anterior em cada commit; também é possível autenticar digitalmente as tags e commits dos desenvolvedores.

Em comparação com a versão anterior, a nova versão inclui 483 alterações, preparadas com a participação de 86 desenvolvedores, dos quais 31 participaram do desenvolvimento pela primeira vez. Principais novidades:

  • No comando 'git shortlog', destinado a exibir resumos estatísticos do histórico de alterações, foi adicionada a opção '--group' para agrupamento arbitrário de commits por campos, sem se limitar ao autor ou ao committer. Por exemplo, para mostrar uma lista de desenvolvedores com informações sobre o número de alterações, considerando co-autores mencionados no campo 'Co-authored-by', pode-se usar o comando: git shortlog -ns --group=author --group=trailer:co-authored-by

    A saída do shortlog pode ser agregada usando especificadores de formatação, e a opção "--group" facilita consideravelmente a criação de relatórios complexos e elimina a necessidade de comandos de ordenação adicionais. Por exemplo, para criar um relatório com informações sobre quantos commits foram aceitos para uma determinada versão a cada mês, você pode usar: git shortlog v2.38.0.. --date='format:%Y-%m' --group='' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Anteriormente, para realizar uma operação semelhante, era necessário o uso das utilidades sort e uniq: git log v2.38.0.. --date='format:%Y-%m' --format='' | sort | uniq -c

  • As funcionalidades do mecanismo "cruft packs" foram ampliadas, destinado à embalagem de objetos inalcançáveis, para os quais não existem referências no repositório (nenhuma branch ou tag faz referência). Objetos inalcançáveis são removidos pelo coletor de lixo, mas permanecem no repositório por um tempo determinado antes da exclusão, a fim de evitar condições de corrida. O mecanismo "cruft packs" permite armazenar todos os objetos inalcançáveis em um único arquivo pack, enquanto os dados sobre o tempo de modificação de cada objeto são refletidos em uma tabela separada, armazenada em um arquivo com a extensão ".mtimes", para que não se sobreponham ao tempo geral de modificação.

    O tempo que os objetos inalcançáveis permanecem no repositório antes da exclusão real é determinado pela opção "—prune=". Embora a demora antes da exclusão seja uma maneira bastante eficaz e prática de evitar a corrupção do repositório devido a condições de corrida, não é 100% confiável. Para facilitar a recuperação de um repositório danificado, na nova versão foi disponibilizada a opção de salvar objetos ausentes, para a qual foi adicionada à equipe "git repack" a opção "—expire-to", permitindo especificar um arquivo para criar uma cópia externa de todos os objetos removidos. Por exemplo, para salvar em um arquivo backup.git os objetos inalcançáveis que não foram modificados nos últimos 5 minutos, pode-se usar o comando: git repack —cruft —cruft-expiration=5.minutes.ago -d —expire-to=../backup.git

  • A velocidade de execução da operação "git grep —cached" ao buscar em áreas onde é aplicado o clone parcial (sparse-checkout) e para as quais existem índices parciais (sparse index) aumentou significativamente (até 70%). Anteriormente, ao especificar a opção "—cached", a busca era primeiro realizada no índice normal e depois nos parciais, o que resultava em delays perceptíveis ao buscar em repositórios grandes.
  • A execução foi acelerada em servidor verificações de integridade de novos objetos antes de serem inseridos no repositório durante a operação "git push". Devido à mudança para considerar apenas referências anunciadas durante a verificação, em um repositório de teste com 7 milhões de referências, das quais apenas 3% estavam cobertas pela operação push, as otimizações realizadas permitiram reduzir o tempo de verificação em 4,5 vezes.
  • Para proteção contra possíveis estouros de inteiros no código, o tamanho máximo dos patches processados na equipe "git apply" foi limitado. Agora, se o tamanho do patch exceder 1 GB, um erro será exibido.
  • Para proteger contra possíveis vulnerabilidades, foram feitas alterações para limpar informações desnecessárias dos cabeçalhos enviadas ao usar o módulo h2h3 com a opção GIT_TRACE_CURL=1 ou GIT_CURL_VERBOSE=1 junto com HTTP/2.
  • Ao executar a operação de checkout com uma branch que é um link simbólico para outra branch, o comando "git symbolic-ref HEAD" agora exibe o nome da branch de destino, em vez do nome do link simbólico.
  • Adicionada a suporte ao argumento @{-1} na opção "—edit-description" ("git branch —edit-description @{-1}") para editar a descrição da branch anterior.
  • Adicionado o comando "git merge-tree —stdin", que permite passar uma lista de parâmetros pela entrada padrão.
  • Em sistemas de arquivos de rede, o manipulador fsmonitor, que rastreia alterações no sistema de arquivos, está desativado por padrão.

Fonte: opennet.ru

Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS 🔥 Compre hospedagem confiável para sites com proteção contra DDoS, servidores VPS VDS | ProHoster