Resumen
- El diseño oficial de transición de 2018 escogió SHA-256 y planteó una correspondencia bidireccional entre nombres antiguos y nuevos. Esa era la meta técnica del proyecto.
- El manual de Git 2.29.0 llamó experimental al formato SHA-256 en 2020. El manual de Git 2.54.0 siguió indicando en 2026 que ambos formatos de repositorio no podían interoperar.
Un nombre escrito dentro de otro
Un blob puede conservar los bytes de un archivo y recibir un identificador calculado con otro algoritmo. Ahí termina la parte sencilla. Los árboles de Git contienen los nombres de archivos y subárboles; los commits contienen el nombre de su árbol y de sus commits padres. Una etiqueta puede apuntar a otro objeto. Según el diseño de transición, cambiar uno de esos nombres altera el contenido del objeto que lo cita, que a su vez recibe un nombre distinto. La historia conectada propaga el cambio. No hay una ventanilla única donde sustituir una cadena y declarar mudado el archivo histórico.
La motivación para abandonar SHA-1 era concreta: el documento discutía sus debilidades y la colisión SHAttered de 2017. La respuesta escogida fue SHA-256. Pero los repositorios ya almacenados, los servidores y las herramientas de terceros seguían manejando los nombres anteriores. Había que saber qué nombre nuevo correspondía a cada nombre viejo. El cálculo criptográfico no aporta por sí mismo esa tabla de equivalencias.
Por eso el plan de 2018 propuso un mapa en ambos sentidos. Aspiraba a convertir repositorios uno por uno y a mantener comunicación con servidores SHA-1. Describía etapas, dejando el soporte de un nuevo protocolo fuera de la primera fase. Es un documento de ingeniería sobre cómo llegar, no una prueba de que los clientes de entonces hubieran llegado.
La opción local no resolvió la conversación
En 2020, el manual de Git 2.29.0 ya ofrecía git init --object-format=sha256. Al lado advertía que el formato era experimental, pensado para pruebas y generalmente incapaz de compartir trabajo con repositorios SHA-1. Poder crear un depósito nuevo no garantiza que los camiones de la red antigua sepan entrar.
En el manual de Git 2.54.0, publicado en 2026, sha1 seguía siendo el formato predeterminado y sha256 una opción. La misma página decía que aún no había interoperabilidad entre repositorios de uno y otro tipo. La comparación de documentos mide una distancia precisa: de un diseño de traducción a una opción utilizable para crear repositorios, sin convertir todavía la colaboración mixta en una capacidad normal.
El documento BreakingChanges prevé que Git 3.0 haga de SHA-256 el valor por defecto para repositorios nuevos. No fija fecha y exige preparación de bibliotecas, aplicaciones y servicios de alojamiento. Tampoco prevé aún eliminar el formato SHA-1. Así, la entrada del edificio puede cambiar antes de que desaparezcan sus antiguos inquilinos. El problema de comunicación entre ambos grupos seguirá teniendo una factura propia.
El coste estaba repartido
Quienes mantienen Git pueden escoger un algoritmo y publicar una opción. No pueden actualizar de una vez todos los repositorios remotos, las bibliotecas y los servicios que leen sus objetos. Cada dependencia conserva parte de la autoridad práctica sobre la migración. La documentación de 2018 hizo visible esa estructura al pedir una traducción de nombres; la de 2026 conserva la advertencia sobre el límite real. Cuando el nombre es también contenido y referencia, la voluntad del proyecto necesita que el resto del sistema la ejecute.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para el Círculo Estratégico
Círculo Estratégico
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete al Círculo EstratégicoSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance





