Git 2.8 (marzo de 2016) incluye una confirmación muy detallada que explica la importancia de msys2 para el nuevo git-for-windows que reemplazó a msysgit a principios de 2015 .
Ver commit df5218b (13 de enero de 2016) por Johannes Schindelin ( dscho
) .
(Fusionada por Junio C Hamano - gitster
- en commit 116a866 , 29 de enero de 2016)
Durante mucho tiempo, Git para Windows se quedó atrás de las versiones 2.x de Git porque los desarrolladores de Git para Windows querían dejar que ese gran salto coincidiera con un salto muy necesario de MSys a MSys2.
Para comprender por qué este es un problema tan grande, debe tenerse en cuenta que muchas partes de Git no están escritas en C portátil, sino que Git se basa en un shell POSIX y Perl para estar disponible .
Para admitir los scripts, Git para Windows tiene que enviar una capa de emulación POSIX mínima con Bash y Perl , y cuando el esfuerzo de Git para Windows comenzó en agosto de 2007, este desarrollador decidió usar MSys, una versión simplificada de Cygwin .
En consecuencia, el nombre original del proyecto era "msysGit" (que, lamentablemente, causó mucha confusión porque pocos usuarios de Windows saben acerca de MSys, y menos aún).
Para compilar el código C de Git para Windows, también se utilizó MSys: tiene dos versiones del compilador C de GNU:
- uno que se vincula implícitamente a la capa de emulación POSIX,
- y otro que apunta a la API Win32 simple (con algunas funciones convenientes incluidas).
Los ejecutables de Git para Windows se crean utilizando este último y, por lo tanto, en realidad son solo programas Win32. Para discernir los ejecutables que requieren la capa de emulación POSIX de los que no, los últimos se denominan MinGW (Minimal GNU para Windows) cuando los primeros se denominan ejecutables de MSys .
Sin embargo, esta dependencia de MSys también generó desafíos:
- algunos de nuestros cambios en el tiempo de ejecución de MSys, necesarios para admitir mejor Git para Windows, no se aceptaron en sentido ascendente, por lo que tuvimos que mantener nuestra propia bifurcación.
- Además, el tiempo de ejecución de MSys no se desarrolló aún más para admitir, por ejemplo, UTF-8 o 64 bits, y aparte de la falta de un sistema de gestión de paquetes hasta mucho más tarde (cuando
mingw-get
se introdujo), muchos paquetes proporcionados por el proyecto MSys / MinGW van a la zaga de los respectivos versiones de código fuente, en particular Bash y OpenSSL.
Durante un tiempo, el proyecto Git para Windows intentó remediar la situación al tratar de construir versiones más nuevas de esos paquetes, pero la situación rápidamente se volvió insostenible, especialmente con problemas como el error Heartbleed que requiere una acción rápida que no tiene nada que ver con el desarrollo de Git para Windows más lejos.
Felizmente, mientras tanto surgió el proyecto MSys2 ( https://msys2.github.io/ ), y fue elegido para ser la base del Git para Windows 2.x.
Al igual que MSys, MSys2 es una versión simplificada de Cygwin, pero se mantiene activamente actualizada con el código fuente de Cygwin .
Por lo tanto, ya es compatible con Unicode internamente, y también ofrece el soporte de 64 bits que anhelamos desde el comienzo del proyecto Git para Windows.
MSys2 también portó el sistema de gestión de paquetes Pacman de Arch Linux y lo usa mucho . Esto brinda la misma conveniencia a la que los usuarios de Linux están acostumbrados desde yum
o apt-get
, y a los que los usuarios de MacOSX están acostumbrados desde Homebrew o MacPorts, o usuarios de BSD desde el sistema Ports, a MSys2: un simple pacman -Syu
actualizará todos los paquetes instalados a las versiones más recientes actualmente disponible.
MSys2 también es muy activo, por lo general, proporciona actualizaciones de paquetes varias veces por semana.
Todavía requirió un esfuerzo de dos meses para llevar todo a un estado donde la suite de prueba de Git pasa, muchos meses más hasta que se lanzó el primer Git oficial para Windows 2.x, y todavía hay un par de parches que esperan su envío a los respectivos proyectos ascendentes . Sin embargo, sin MSys2, la modernización de Git para Windows simplemente no habría sucedido .
Este compromiso sienta las bases para soportar las compilaciones de Git basadas en MSys2.
En los comentarios , se hizo la pregunta en enero de 2016:
Dado que Git para Windows ya está basado en MSYS2, ¿los binarios que no dependen de la capa de emulación están disponibles como un paquete MSYS2?
Ray Donnelly respondió en ese momento:
Todavía no nos hemos fusionado por completo, no. Aunque estamos trabajando en eso.
Pero ... madz señala que a principios de 2017, ese esfuerzo no funcionó.
Ver:
El problema es que no puedo aportar cambios que den como resultado un nuevo tiempo de ejecución de msys2 de manera oportuna.
Sin embargo, no es un gran problema: solo mantendré la bifurcación de Git para Windows ejecutándose indefinidamente.
La wiki por lo tanto menciona ahora (2018):
Git para Windows creó algunos parches para msys2-runtime que no se han enviado en sentido ascendente. (Esto se había planeado, pero se determinó en el número 284 que probablemente no sucedería).
Esto significa que debe instalar Git para Windows msys2-runtime personalizado para tener un git totalmente funcional dentro de MSYS2.
Tenga en cuenta que, desde que confirmó aeb582a9 (Git 2.22, Q2 2019), el proyecto Git para Windows inició el proceso de actualización a una versión de tiempo de ejecución MSYS2 basada en Cygwin v3.x.
mingw
: permite construir con un tiempo de ejecución MSYS2 v3.x
Recientemente, el proyecto Git para Windows inició el proceso de actualización a una versión en tiempo de ejecución MSYS2 basada en Cygwin v3.x.
Esto tiene la notable consecuencia de que $(uname -r)
ya no informa una versión que comienza con "2", sino una versión con "3".
Eso rompe nuestra compilación, ya que df5218b ( config.mak.uname
: soporte MSys2, 2016-01-13, Git v2.8.0-rc0) simplemente no esperaba que la versión informada uname -r
dependiera de la versión subyacente de Cygwin: esperaba que la versión informada coincidiera con el " 2 "en" MSYS2 ".
Así que invirtamos ese caso de prueba para probar cualquier otra cosa que no sea una versión que comience con "1" (para MSys).
Eso debería protegernos para el futuro, incluso si Cygwin termina lanzando versiones como 314.272.65536.
Git 2.22 (Q2 2019) preparará para el futuro una prueba contra una actualización de MSYS2 runtime v3.x series.
Ver commit c871fbe (07 de mayo de 2019) por Johannes Schindelin ( dscho
) .
(Fusionada por Junio C Hamano - gitster
- en commit b20b8fe , 19 de mayo de 2019)
t6500(mingw)
: use el PID de Windows del shell
En Git para Windows, utilizamos el MSYS2 Bash que hereda un modelo PID no estándar de la capa de emulación POSIX de Cygwin: cada proceso MSYS2 tiene un PID de Windows normal y, además, tiene un PID MSYS2 (que corresponde a un proceso sombra que emula Manejo de señal estilo Unix).
Con la actualización al tiempo de ejecución MSYS2 v3.x, ya no se puede acceder a este proceso OpenProcess()
oculto, y por lo tanto t6500 pensó incorrectamente que el proceso al que se hace referencia gc.pid
(que en realidad no es un gc
proceso real en este contexto, pero el shell actual) ya no existe
Arreglemos esto asegurándonos de que el PID de Windows esté escrito
gc.pid
en este script de prueba para que git.exe
pueda comprender que ese proceso todavía existe.