{"id":118622,"date":"2024-07-30T09:43:00","date_gmt":"2024-07-30T07:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46"},"modified":"2024-07-30T09:43:00","modified_gmt":"2024-07-30T07:43:00","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-46","title":{"rendered":"Lanzamiento del sistema de control de versiones Git 2.46","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de tres meses de desarrollo, se ha publicado la versi\u00f3n 2.46 del sistema distribuido de control de versiones Git. Git es uno de los sistemas de control de versiones m\u00e1s populares, confiables y de alto rendimiento, que ofrece herramientas flexibles para el desarrollo no lineal, basadas en la ramificaci\u00f3n y la fusi\u00f3n de ramas. Para garantizar la integridad del historial y la resistencia a cambios \"retroactivos\", se utiliza un hashing impl\u00edcito de toda la historia anterior en cada commit, adem\u00e1s de la posibilidad de autenticar digitalmente las firmas de los desarrolladores de 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, se han incorporado 746 cambios en esta nueva versi\u00f3n, realizados por 96 desarrolladores, de los cuales 31 participan por primera vez en el desarrollo. Principales novedades: <\/p>\n
\n
Se ha a\u00f1adido soporte experimental para un nuevo tipo de mapas de bits \u2014 \"pseudo-merge reachability bitmap\", en los que a diferencia de la estructura \"reachability bitmap\", los datos sobre conjuntos de objetos relacionados con los commits se almacenan no vinculados a cada commit individual, sino vinculados a varios commits. Esta organizaci\u00f3n permite utilizar un solo mapa de bits al determinar objetos para commits en diferentes ramas, lo que en grandes repositorios permite evitar la creaci\u00f3n de un gran n\u00famero de mapas de bits separados y acelera significativamente el recorrido de objetos para determinar qu\u00e9 objetos deben enviarse al cliente durante operaciones como \"git fetch\", \"git rev-list\" y \"git clone\". Para activar este nuevo tipo de mapas de bits y definir la l\u00f3gica de su selecci\u00f3n y uso, se ha propuesto una serie de configuraciones \"bitmapPseudoMerge\": git config bitmapPseudoMerge.all.pattern 'refs\/(heads|tags)\/' git config bitmapPseudoMerge.all.threshold now git config bitmapPseudoMerge.all.stableThreshold never git repack -adb\n
Se ha implementado una nueva interfaz de l\u00ednea de comandos para el comando \"git config\", donde en lugar de opciones dispersas para ver, renombrar y eliminar configuraciones y secciones, como \"--get\", \"--get-all\", \"--unset\" y \"--remove-section\", se ofrece un conjunto separado de subcomandos. Por ejemplo, para listar todas las configuraciones del repositorio ahora se puede usar el comando \"git config list\", y para ver el contenido de un par\u00e1metro espec\u00edfico \u2014 el comando \"git config get \". Para una filtraci\u00f3n adicional de resultados, con la opci\u00f3n \"--regexp\" se puede establecer un filtro basado en expresiones regulares.\n
En el protocolo «credential helper», utilizado para transmitir credenciales al acceder a repositorios con acceso restringido, se ha a\u00f1adido soporte para nuevos campos «authtype» y «credential», que permiten crear manejadores para sistemas de autenticaci\u00f3n HTTP que no se limitan a la verificaci\u00f3n de usuario y contrase\u00f1a, por ejemplo, al usar Bearer Token en OAuth 2.0. Antes, para trabajar con tales sistemas de autenticaci\u00f3n, era necesario especificar datos confidenciales en texto claro en el par\u00e1metro http.extraHeader. Adem\u00e1s, se ha a\u00f1adido al protocolo la posibilidad de guardar el estado de cada manejador de credenciales para soportar m\u00e9todos de autenticaci\u00f3n por etapas, utilizados en protocolos como NTLM y Kerberos.\n
Se ha continuado el desarrollo del backend experimental «reftable» para el almacenamiento eficiente en el repositorio de referencias a ramas y etiquetas. Este backend utiliza almacenamiento en bloques, implementado por el proyecto JGit y optimizado para almacenar un n\u00famero muy grande de referencias (los formatos tradicionales de almacenamiento de referencias generan costos significativos en repositorios con un gran n\u00famero de referencias debido a la colocaci\u00f3n de un n\u00famero muy grande de archivos en un mismo directorio al almacenar referencias en el directorio $GIT_DIR\/refs o a la necesidad de reescribir un \u00fanico archivo grande en cada actualizaci\u00f3n al almacenar referencias en el archivo $GIT_DIR\/packed_refs). En la nueva versi\u00f3n se ha a\u00f1adido el comando «git refs migrate —ref-format=reftable» para migrar repositorios existentes al backend «reftable» (anteriormente, el backend solo se activaba al inicializar el repositorio).\n
Se ha a\u00f1adido a la herramienta git la opci\u00f3n «—no-advice», que desactiva todos los mensajes de recomendaciones y sugerencias, lo que puede ser \u00fatil para evitar la saturaci\u00f3n del log con informaci\u00f3n innecesaria durante la invocaci\u00f3n automatizada de git.\n
Se ha iniciado el proceso de traducci\u00f3n de algunas comprobaciones del conjunto de pruebas para utilizar pruebas unitarias, lo que simplificar\u00e1 la prueba de componentes de bajo nivel y mejorar\u00e1 la eficiencia del proceso de pruebas en la plataforma Windows, donde existen grandes cargas al ejecutar un gran n\u00famero de procesos durante la ejecuci\u00f3n de pruebas implementadas como scripts de shell.\n
Se ha a\u00f1adido al c\u00f3digo para el an\u00e1lisis de configuraciones de colores la posibilidad de usar la representaci\u00f3n «#RGB» adem\u00e1s de «#RRGGBB». <\/ul>\n