{"id":103816,"date":"2022-04-19T15:36:47","date_gmt":"2022-04-19T13:36:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-36"},"modified":"2022-04-19T15:36:47","modified_gmt":"2022-04-19T13:36:49","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-36","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-36","title":{"rendered":"Lanzamiento del sistema de control de versiones Git 2.36","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de tres meses de desarrollo, se public\u00f3 la versi\u00f3n 2.36 del sistema de control de versiones distribuido Git. Git es uno de los sistemas de control de versiones m\u00e1s populares, confiables y de alto rendimiento, que ofrece flexibles 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 toda la historia anterior en cada commit, siendo posible tambi\u00e9n la certificaci\u00f3n con firmas digitales de los desarrolladores para etiquetas y commits espec\u00edficos. <\/p>\n
En comparaci\u00f3n con la versi\u00f3n anterior, se han aceptado 717 cambios en la nueva versi\u00f3n, preparados con la participaci\u00f3n de 96 desarrolladores, de los cuales 26 participaron por primera vez en el desarrollo. Principales novedades: <\/p>\n
\n
El comando 'git log' y 'git show' se ha a\u00f1adido la opci\u00f3n '--remerge-diff', que permite mostrar las diferencias entre el resultado conjunto de la fusi\u00f3n y los datos reales reflejados en el commit despu\u00e9s de procesar el comando 'merge', lo que permite evaluar visualmente los cambios realizados como resultado de la resoluci\u00f3n de conflictos durante la fusi\u00f3n. El comando 'git show' habitual separa las diferentes resoluciones de conflictos con sangr\u00edas, lo que dificulta la comprensi\u00f3n de los cambios. Por ejemplo, en la captura de pantalla a continuaci\u00f3n, las l\u00edneas '+\/-' sin sangr\u00eda muestran la \u00faltima resoluci\u00f3n de conflicto relacionada con el cambio de nombre en la primera rama de sha1 a oid en el comentario, mientras que '+\/-' con sangr\u00eda muestra la resoluci\u00f3n inicial de conflicto, causada por la aparici\u00f3n en la segunda rama de un argumento adicional en la funci\u00f3n dwim_ref().
<\/center>\n
Al utilizar la opci\u00f3n '--remerge-diff', las diferencias entre las resoluciones de conflictos no se separan para cada rama principal, 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.
<\/center> <\/p>\n
Se ha mejorado la flexibilidad en la configuraci\u00f3n del comportamiento de restablecimiento de cach\u00e9s en disco a trav\u00e9s de la llamada a la funci\u00f3n fsync(). El par\u00e1metro previamente disponible core.fsyncObjectFiles se ha dividido en dos variables de configuraci\u00f3n core.fsync y core.fsyncMethod, que ofrecen la capacidad de aplicar fsync no solo a los archivos de objetos (.git\/objects), sino tambi\u00e9n a otras estructuras de git, como referencias (.git\/refs), reflog y archivos de paquetes.\n
A trav\u00e9s de la variable core.fsync se puede especificar una lista de estructuras internas de Git para las cuales se invocar\u00e1 fsync adicionalmente despu\u00e9s de una operaci\u00f3n de escritura. La variable core.fsyncMethod permite seleccionar el m\u00e9todo para vaciar la cach\u00e9, por ejemplo, se puede elegir fsync para aplicar la llamada al sistema del mismo nombre o especificar writeout-only para aplicar la escritura diferida (escritura en cach\u00e9 de p\u00e1ginas). <\/p>\n
Para protegerse contra vulnerabilidades que manipulan la sustituci\u00f3n de directorios .git por otros usuarios en secciones compartidas, se ha reforzado la verificaci\u00f3n del propietario del repositorio. La ejecuci\u00f3n de cualquier comando git ahora solo se permite en sus propios directorios '.git'. Si el directorio del repositorio pertenece a otro usuario, por defecto se mostrar\u00e1 un error. Este comportamiento se puede desactivar mediante la configuraci\u00f3n safe.directory.\n
Al comando «git cat-file», dise\u00f1ado para mostrar el contenido de los objetos de Git, se le ha a\u00f1adido la opci\u00f3n «—batch-command», que complementa los comandos disponibles anteriormente «—batch» y «—batch-check», permitiendo seleccionar de forma adaptativa el tipo de salida a trav\u00e9s de la indicaci\u00f3n «contents <objeto>» para mostrar el contenido o «info <objeto>» para mostrar informaci\u00f3n sobre el objeto. Adem\u00e1s, se admite el comando «flush» para vaciar el b\u00fafer de salida.\n
Al comando «git ls-tree», destinado a formar una lista del contenido del \u00e1rbol de objetos, se le ha a\u00f1adido la opci\u00f3n «—oid-only» («—object-only»), que, al igual que «—name-only», solo muestra los identificadores de los objetos para facilitar su uso en scripts. Tambi\u00e9n se ha implementado la opci\u00f3n «—format» que permite definir un formato de salida propio, combinando informaci\u00f3n sobre el modo, tipo, nombre y tama\u00f1o.\n
En el comando «git bisect run» se ha implementado la determinaci\u00f3n de si el script no tiene el indicador de archivo ejecutable y, en ese caso, se muestra un error con los c\u00f3digos 126 o 127 (anteriormente, si no se pod\u00eda ejecutar el script, todas las revisiones se marcaban como problem\u00e1ticas).\n
Al comando «git fetch» se le ha a\u00f1adido la opci\u00f3n «—refetch» para extraer todos los objetos sin informar a la otra parte sobre el contenido que ya se tiene en el sistema local. Este comportamiento puede ser \u00fatil para restaurar el estado despu\u00e9s de fallos, cuando no se tiene certeza sobre la integridad de los datos locales.\n
A los comandos «git update-index», «git checkout-index», «git read-tree» y «git clean» se les ha a\u00f1adido soporte para \u00edndices parciales (sparse index), lo que permite mejorar el rendimiento y ahorrar espacio en los repositorios donde se realizan operaciones de clonaci\u00f3n parcial (sparse-checkout).\n
Se ha cambiado el comportamiento del comando «git clone —filter=… —recurse-submodules», que ahora resulta en una clonaci\u00f3n parcial de subm\u00f3dulos (anteriormente, cuando se ejecutaban comandos as\u00ed, el filtro se aplicaba solo al contenido principal, y los subm\u00f3dulos se clonaban completamente sin considerar el filtro).\n
En el comando «git bundle» se ha a\u00f1adido soporte para la especificaci\u00f3n de filtros para la inclusi\u00f3n selectiva de contenido, similar a las operaciones de clonaci\u00f3n parcial.\n
Al comando «git branch» se le ha a\u00f1adido la opci\u00f3n «—recurse-submodules» para la navegaci\u00f3n recursiva a trav\u00e9s de subm\u00f3dulos.\n
Se ha propuesto un nuevo procesador para el lenguaje Kotlin en userdiff. <\/ul>\n
![\"Lanzamiento](\"\/wp-content\/uploads\/2022\/04\/75651aa0f36ad2b5896991a675754b1f.jpg\")
<\/center>\n![\"Lanzamiento](\"\/wp-content\/uploads\/2022\/04\/903ff119e179781b6e0de91205765a6a.jpg\")
<\/center> <\/p>\n