{"id":121313,"date":"2025-01-11T21:46:00","date_gmt":"2025-01-11T19:46:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-48"},"modified":"2025-01-11T21:46:00","modified_gmt":"2025-01-11T19:46:00","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-48","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-48","title":{"rendered":"Lanzamiento del sistema de control de versiones Git 2.48","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Se ha publicado la versi\u00f3n del sistema de control de versiones distribuido Git 2.48. Git destaca por su alta rendimiento y ofrece herramientas para el desarrollo no lineal, basadas en ramificaciones y fusiones de ramas. Para asegurar la integridad del historial y la resistencia a cambios 'retroactivos', se utiliza un hash impl\u00edcito de todo el historial anterior en cada commit, as\u00ed como la certificaci\u00f3n mediante firmas digitales de los desarrolladores para etiquetas y commits individuales. El c\u00f3digo de Git se distribuye bajo la licencia GPLv2+. <\/p>\n
En comparaci\u00f3n con la versi\u00f3n anterior, en esta nueva versi\u00f3n se han incluido 605 cambios, realizados por 93 desarrolladores, de los cuales 35 participan por primera vez en el desarrollo. Principales novedades: <\/p>\n
\n
Se ha implementado la posibilidad de construir utilizando el sistema de construcci\u00f3n Meson, adem\u00e1s de GNU Make y CMake. Para construir Git, ahora se puede usar el comando 'meson setup build && ninja -C build'. Se se\u00f1ala que el Makefile utilizado al emplear GNU Make ha crecido hasta 3887 l\u00edneas y no es tan sencillo como se desear\u00eda. La herramienta Meson simplifica el trabajo con el sistema de construcci\u00f3n, es conveniente para compilaciones multiplataforma y hace que la construcci\u00f3n sea m\u00e1s accesible para principiantes o desarrolladores sin experiencia con el programa Make. No est\u00e1 previsto dejar de dar soporte a Make y CMake en un futuro pr\u00f3ximo.\n
Se han a\u00f1adido opciones de construcci\u00f3n que permiten utilizar implementaciones alternativas del hash SHA-1 al calcular las sumas de verificaci\u00f3n que se utilizan para verificar la integridad de los bloques de datos en archivos pack. El rendimiento del c\u00e1lculo de sumas de verificaci\u00f3n es crucial; por ejemplo, aproximadamente el 78% del tiempo de CPU se gasta en el c\u00e1lculo de sumas de verificaci\u00f3n al clonar un repositorio del n\u00facleo de Linux. La implementaci\u00f3n predeterminada incluye verificaciones adicionales de colisiones y protecci\u00f3n contra ataques a SHA-1, como SHAttered y Shambles. Esta protecci\u00f3n, que consume recursos adicionales, solo tiene sentido al utilizar SHA-1 con fines criptogr\u00e1ficos y es in\u00fatil para verificar la integridad de los datos indexados.\n
Para construir Git con una implementaci\u00f3n m\u00e1s r\u00e1pida de SHA-1, que no es adecuada para sistemas criptogr\u00e1ficos, se ha propuesto una serie de opciones *_UNSAFE, como 'OPENSSL_SHA1_UNSAFE'. En GitHub, la construcci\u00f3n con el SHA-1 simplificado ha permitido aumentar el rendimiento de las operaciones de extracci\u00f3n y clonaci\u00f3n de datos entre un 10% y un 13%. <\/p>\n
Se ha a\u00f1adido la opci\u00f3n '\u2014remerge-diff' al comando 'range-diff', que permite mostrar las diferencias entre el resultado total de la fusi\u00f3n y los datos reales reflejados en el commit despu\u00e9s de procesar el comando 'merge'. Al usar la opci\u00f3n '\u2014remerge-diff', las diferencias entre las resoluciones de conflictos no se separan para cada rama padre, sino que se muestran las diferencias generales entre el archivo que tiene conflictos de fusi\u00f3n y el archivo en el que se han resuelto los conflictos. En el contexto del comando 'range-diff', la nueva opci\u00f3n puede ser \u00fatil para comparar conjuntos de commits despu\u00e9s de trasladar la secuencia de commits con el comando 'rebase' y la opci\u00f3n '\u2014rebase-merges'.\n
Se ha a\u00f1adido la posibilidad de ejecutar un conjunto de pruebas de Git con la activaci\u00f3n del modo de detecci\u00f3n de fugas de memoria. Dado que Git proporciona utilidades que cierran despu\u00e9s de ejecutar la funci\u00f3n llamada, las fugas de memoria no se consideraban un gran problema anteriormente. La necesidad de erradicar completamente las fugas de memoria se ha vuelto relevante tras el comienzo del trabajo para trasladar la funcionalidad interna a una biblioteca separada, que puede ser utilizada en procesos de larga duraci\u00f3n.\n
Se ha comenzado a elaborar una lista de modos y caracter\u00edsticas obsoletas, cuyo soporte se planea eliminar en el futuro. Se espera que la eliminaci\u00f3n de la funcionalidad obsoleta ocurra en la versi\u00f3n 3.0 de Git, que incluir\u00e1 cambios que rompen la compatibilidad hacia atr\u00e1s.\n
Se ha continuado la optimizaci\u00f3n del funcionamiento del comando «git for-each-ref», que genera una lista de referencias en el repositorio. La optimizaci\u00f3n, que combina los manejadores para filtrar referencias y formatear la salida, ahora se aplica no solo para la salida no ordenada, sino tambi\u00e9n al especificar la opci\u00f3n «—sort».\n
Se ha mejorado la implementaci\u00f3n del backend «reftable» con almacenamiento en bloques para un almacenamiento eficiente de las referencias a ramas y etiquetas en el repositorio. Reftable permite acelerar considerablemente la b\u00fasqueda, lectura y escritura en repositorios con un gran n\u00famero de referencias. En la nueva versi\u00f3n, se ha dejado de acceder a ciertas API auxiliares para excluir a\u00fan m\u00e1s la biblioteca libgit de las dependencias de compilaci\u00f3n. Se ha implementado un manejo adaptable de errores devueltos por funciones de asignaci\u00f3n de memoria (la falta de memoria ya no causa un cierre inesperado). Se han acelerado las operaciones de creaci\u00f3n de referencias y reducido el consumo de memoria.\n
En la implementaci\u00f3n de la clonaci\u00f3n parcial, se han resuelto problemas que causaban bucles y corrupci\u00f3n del repositorio tras ejecutar el comando «git gc».\n
Al ejecutar el comando «git fetch <remote>», en caso de que no exista en el sistema local «refs\/remotes\/<remote>\/HEAD» y haya una rama en el otro extremo a la que apunta HEAD, «refs\/remotes\/<remote>\/HEAD» ahora se redirige hacia esa rama. Para gestionar la sincronizaci\u00f3n de «refs\/remotes\/<remote>\/HEAD» con el valor de HEAD en el otro extremo de la conexi\u00f3n, se ha a\u00f1adido la configuraci\u00f3n remote.<remote>.followRemoteHEAD».\n
Se ha a\u00f1adido la configuraci\u00f3n «remote.<name>.serverOption» que es an\u00e1loga a la opci\u00f3n de l\u00ednea de comandos «—serverOption=<value>».\n
En el comando «git rebase —rebase-merges» se asegura, siempre que sea posible, el uso de los nombres de las ramas como etiquetas.\n
En los comandos ‘git notes add’ y ‘git notes append’ se ha a\u00f1adido el flag ‘-e’, que abre la nota en un editor de texto externo especificado a trav\u00e9s de la variable de entorno GIT_EDITOR.\n
Se ha mejorado la compatibilidad con GCC 15 y el est\u00e1ndar C23.\n
Se ha dejado de dar soporte a versiones antiguas de libcURL y Perl. <\/ul>\n