Versión de control de fonte de Git 2.39

Despois de dous meses de desenvolvemento, lanzouse o sistema de control de fontes distribuído Git 2.39. Git é un dos sistemas de control de versións máis populares, fiables e de alto rendemento, que ofrece ferramentas de desenvolvemento flexibles e non lineais baseadas en ramificación e fusión. Para garantir a integridade do historial e a resistencia aos cambios retroactivos, en cada commit utilízase o hash implícito de todo o historial anterior; tamén é posible certificar etiquetas e commits individuais con sinaturas dixitais dos desenvolvedores.

En comparación coa versión anterior, a nova versión incluíu 483 cambios, preparados coa participación de 86 desenvolvedores, dos cales 31 participaron no desenvolvemento por primeira vez. Principais novidades:

  • O comando "git shortlog", deseñado para mostrar resumos con estatísticas do historial de cambios, engadiu unha opción "-group" para agrupar arbitrariamente as confirmacións por campos non limitadas ao autor ou ao autor. Por exemplo, para mostrar unha lista de desenvolvedores con información sobre o número de cambios, tendo en conta os axudantes mencionados no campo "Co-authored-by", pode usar o comando: git shortlog -ns --group=author - -group=tráiler:coautor

    A saída de Shortlog pódese agregar mediante especificadores de formato e a opción "--group" pode simplificar significativamente a creación de informes complexos e eliminar a necesidade de comandos de clasificación adicionais. Por exemplo, para crear un informe con información sobre cantos commits para unha versión determinada se aceptaron cada mes, pode especificar: git shortlog v2.38.0.. —date='format:%Y-%m' —group=' %cd' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Anteriormente, para realizar unha operación similar sería necesario empregar as utilidades sort e uniq: git log v2.38.0 .. —date='formato:%Y -%m' —format='%cd' | ordenar | único -c

  • Ampliáronse as capacidades do mecanismo "cruft packs", deseñado para empaquetar obxectos inalcanzables que non están referenciados no repositorio (non referenciados por ramas ou etiquetas). Os obxectos inalcanzables son eliminados polo colector de lixo, pero permanecen no repositorio durante un tempo determinado antes de ser eliminados para evitar condicións de carreira. O mecanismo "cruft packs" permítelle almacenar todos os obxectos inalcanzables nun ficheiro de paquete e mostrar os datos sobre o tempo de modificación de cada obxecto nunha táboa separada, almacenada nun ficheiro separado coa extensión ".mtimes", para que o fagan. non se solape co tempo total de modificación.

    O período de tempo que permanecen no repositorio os obxectos inalcanzables antes de que se eliminen está determinado pola opción "—prune=" " Non obstante, aínda que atrasar antes de eliminar é unha forma bastante eficaz e práctica de evitar a corrupción do repositorio debido ás condicións de carreira, non é fiable ao 100%. Para facilitar a restauración dun repositorio danado, a nova versión ofrece a posibilidade de gardar os obxectos que faltan engadindo a opción "--expire-to" ao comando "git repack", que che permite especificar un ficheiro para crear un ficheiro externo. copia de todos os obxectos eliminados. Por exemplo, para gardar obxectos inalcanzables que non cambiaron nos últimos 5 minutos no ficheiro backup.git, pode usar o comando: git repack --cruft --cruft-expiration=5.minutes.ago -d --expire -to=../backup.git

  • Aumentou significativamente (ata un 70%) a velocidade da operación "git grep -cached" cando se busca en áreas que usan clonación parcial (sparse-checkout) e para as que hai índices parciais (sparse index). Anteriormente, ao especificar a opción "-cached", a busca realizábase primeiro no índice regular, e despois nos parciais, o que provocou notables atrasos á hora de buscar en grandes repositorios.
  • Acelerouse a verificación do servidor da coherencia dos novos obxectos antes de colocalos no repositorio durante a operación "git push". Ao pasar a contabilizar só as ligazóns declaradas ao comprobar, nun repositorio de probas con 7 millóns de ligazóns, das que só o 3% está cuberto pola operación push, as optimizacións realizadas permitiron reducir o tempo de comprobación en 4.5 veces.
  • Para protexerse contra posibles desbordamentos de números enteiros no código, o comando "git apply" limita o tamaño máximo de parches que se poden procesar. Se o tamaño do parche supera 1 GB, agora aparecerá un erro.
  • Para protexerse de posibles vulnerabilidades, fixéronse cambios para limpar información innecesaria das cabeceiras configuradas ao utilizar o módulo h2h3 coa opción GIT_TRACE_CURL=1 ou GIT_CURL_VERBOSE=1 xunto con HTTP/2.
  • Cando se realiza unha verificación nunha rama que é unha ligazón simbólica a outra rama, o comando "git symbolic-ref HEAD" agora mostra o nome da rama de destino en lugar do nome da ligazón simbólica.
  • Engadiuse soporte para o argumento @{-1} á opción "--edit-description" ("git branch —edit-description @{-1}") para editar a descrición dunha rama anterior.
  • Engadiuse o comando "git merge-tree --stdin" para pasar unha lista de opcións mediante a entrada estándar.
  • Nos sistemas de ficheiros de rede, o manejador fsmonitor, que supervisa os cambios no sistema de ficheiros, está desactivado por defecto.

Fonte: opennet.ru

Engadir un comentario