Se ha lanzado Git 2.33, que incluye un nuevo proceso de combinación opcional llamado merge-ort, que el equipo espera que se convierta en el estándar en la próxima versión.
Los lanzamientos de Git son relativamente frecuentes. Git 2.31 se lanzó en marzo y Git 2.32 en junio. De acuerdo con anuncio de lanzamiento, la versión 2.33 «no tiene muchos cambios orientados al usuario final y nuevas características», además de correcciones y mejoras internas, pero hay un gran cambio, descrito como un «backend de nueva estrategia de fusión».
La estrategia en cuestión es merge-ort, donde ort significa «gemelo aparentemente recursivo», de acuerdo con su creador Elijah Newren.
Una estrategia de combinación es el mecanismo que se utiliza para combinar código de varias versiones de la misma base de código. La fusión es una característica fundamental de los sistemas de control de versiones distribuidos, ya que evita la necesidad de bloquear una versión principal cuando se está editando una copia extraída. Los mecanismos de fusión funcionan comparando el contenido de un archivo con el contenido de su antecesor para identificar las secciones modificadas y luego comparando las secciones modificadas de un archivo con las de otro.
Sin embargo, no siempre puede haber un único archivo antecesor, en cuyo caso se puede utilizar una combinación recursiva para combinar candidatos antepasados y luego tratar el archivo combinado como antepasado. «Se informó que esto dio como resultado menos conflictos de fusión sin causar errores de fusión mediante pruebas realizadas en confirmaciones de fusión reales tomadas del historial de desarrollo del kernel de Linux 2.6», dicen los documentos. Merge-recursive es el valor predeterminado de Git. Otro, llamado pulpo, está diseñado para fusionar archivos con más de dos cabezas y es el predeterminado al fusionar más de una rama.
Taylor Blau, ingeniero de software sénior en GitHub dicho esta fusión recursiva ha tenido «varios errores a lo largo de los años en torno a casos complicados» y que, en algunos casos grandes, «puede ser muy lenta». Merge-ort, dijo, «es una reescritura desde cero» que utilizó los mismos conceptos, pero «resolviendo muchos de los problemas de corrección y rendimiento de larga data».
En una operación de ejemplo, merge-ort fue más de 9.000 veces más rápido que merge-recursive, dijo, mientras que en otro caso «muy complicado» fue 500 veces más rápido. También dijo que merge-ort está mejor optimizado para no acceder a partes sin cambios de un árbol de fuentes y es más adecuado para la integración con otras herramientas. En esta publicaciónNewren resume los beneficios de merge-ort en las áreas de capacidad de reparación, extensibilidad y rendimiento. Merge-ort se puede usar en Git 2.33 con el comando:
merge -s ort
Hay algunos otros cambios menores en 2.33, incluidas mejoras en el comando send-email, un guía para documentación neutra en cuanto al género y otras actualizaciones de la documentación «para que no se asuma que los usuarios son de un género determinado».
Git, desarrollado por Linus Torvalds para código Linux, ahora domina los sistemas de control de versiones, pero no es el más fácil ni el más intuitivo de usar. Dr. D Richard Hipp, creador del administrador de base de datos Sqlite, así como un administrador de control de versiones concurrente llamado Fossil, considerar el comando Git Rebase es dañino y no le gusta la imposibilidad de editar los comentarios registrados, entre otras cosas. «El modelo mental de Git es innecesariamente complejo», dicho.
Git 2.33 no es más simple que antes, pero una combinación más rápida y precisa es una mejora inconfundible. ®
