Git 2.56 llega en versión candidata mientras se decide el salto a 3.0
La versión 2.56 del sistema de control de versiones entra en fase candidata con mejoras de usabilidad, mientras el proyecto debate si el 3.0, con SHA-256 por defecto, debe ser la siguiente entrega.
Git 2.56 ya está en fase de versión candidata y debería salir a finales de septiembre. Lleva algo más de 700 commits sin fusiones, con mejoras de usabilidad y correcciones, y no altera de arriba abajo la experiencia de quien usa Git a diario. Lo interesante es lo que viene detrás: Junio Hamano, mantenedor del proyecto, preguntó a la comunidad a comienzos de septiembre si toca publicar ya el esperado Git 3.0 o si conviene sacar antes una o más versiones 2.x.
Qué trae 2.56
La novedad con más recorrido es el subcomando drop dentro de git history, la caja de herramientas todavía experimental para reescribir historial. git history drop commit-id elimina el commit indicado de la rama actual y vuelve a aplicar todo lo que venía después, lo que simplifica deshacerse de un commit problemático. El problema es que sigue negándose a funcionar si el historial tiene commits de fusión, así que en muchos repositorios no sirve.
git status ahora sugiere un git pull cuando la rama va por detrás de la que sigue, aunque sigue diciendo que está "al día" si lo que hay por delante es una rama remota que no se ha traído. git refs, la herramienta de bajo nivel para manipular referencias, gana los subcomandos create, delete, update y rename. También hay detalles menores: --delete-merged en git branch borra ramas locales ya integradas en su remota, git branch -d avisa y falla si la rama se está usando para hacer bisect, los intentos de bloquear el fichero de configuración se reintentan en vez de rendirse, y git add estrena --resolved para añadir solo los ficheros cuyo conflicto ya se ha resuelto.
El 3.0 y sus rupturas de compatibilidad
El 3.0 arrastra cambios que rompen compatibilidad, y eso explica las dudas. El más gordo es pasar a SHA-256 por defecto en lugar del SHA-1 que Git usa desde el principio. Los hashes identifican cada objeto del repositorio y encadenan los commits, así que un SHA-1 roto permitiría alterar historial sin que se note. El soporte no experimental de SHA-256 existe desde la 2.42, en 2023, y GitLab lo admite desde 2024, igual que Forgejo. Falta GitHub, y publicar una versión de Git que genere repositorios incompatibles con GitHub es un riesgo que el proyecto no ha querido asumir. brian m. carlson, empleado de GitHub e impulsor de la transición, respondió a Hamano que habrá noticias al respecto y que quizá lo mejor sea que la próxima entrega sea la 3.0.
carlson quiere además que Git deje de aceptar identificadores en mayúsculas: hoy f00f00 y F00F00 son el mismo objeto, y esa ambigüedad ha dado lugar a fallos y a alguna vulnerabilidad. El otro cambio que espera al 3.0 es el mecanismo reftable para almacenar referencias, que sustituye el actual de un fichero por referencia bajo .git/refs.
Para quien mantiene infraestructura, la pregunta práctica es cuándo actualizar. 2.56 es una actualización segura. El 3.0 obligará a revisar integraciones, espejos y herramientas que asumen SHA-1, y buena parte de eso depende de que GitHub mueva ficha.
