GitLab vs Gitea

Minientrada

No entiendo por qué GitLab se ha convertido en la implementación de referencia para alojar repositorios con funciones extras como tareas, peticiones de integración o cuentas de usuario. Es lento, dificil de utilizar, dificil de instalar… y además, es un software que se sigue llamando «libre» porque tiene una versión comunitaria, pero que vista la capa de marketing que tiene como producto, no se siente tan libre.

Y sin embargo es lo que plataformas como GNOME, Xfce o Free Desktop han instalado en los últimos años como alternativa a los clientes más duros pero simples como cgit. Una alternativa mucho más ligera que dispone de funciones web es Gitea. Una de las cosas buenas de las aplicaciones web hechas en Go es que igualmente se distribuyen como un binario que se puede arrancar de la forma que haga falta. Configurar un GitLab es absurdamente complicado.

Borrando ramas locales de Git que ya no existen en remoto

Minientrada

En la mayoría de mis repositorios Git, correr git branch suele suponer abrir un cubo de basura bien grande. Cuando una rama de Git desaparece en el remoto (por ejemplo, en GitHub cuando se borra desde la interfaz web automáticamente), luego te tienes que acordar en local de borrar también tu rama. De lo contrario, vas a acabar con ramas stale que son aquellas de las que se hizo git push para abrir PR y que quedan ahí.

Una forma de identificar estas ramas es hacer un git fetch --prune, manteniendo ese prune para que se ocupe de detectar qué ramas han desaparecido del remoto, seguido de git branch -vv | grep gone. En el modo verbose de branch, las ramas locales que hacen tracking de un remoto que ya no está se identifican porque aparece [gone] en su línea de terminal. Por lo que esta pipeline lista únicamente esas ramas locales que han desaparecido del repositorio remoto.

Cortando la primera columna (mejor con awk '{ print $1 }' aunque con cut también se pueda hacer), puedes listar únicamente los nombres de las ramas. Y si estás de acuerdo con la salida de git branch -vv | grep gone | awk '{ print $1 }', (y sólo si estás de acuerdo, porque ya sabes, no refunds), entonces puedes envolver todo en un git branch -D $(git branch -vv | grep gone | awk '{ print $1 }') para cargarte todas esas ramas de un plumazo.

¿Qué hacemos cuando hay conflicto en el Gemfile.lock?

Minientrada

Pues esta es fácil pero como todo en Git nunca aparente. Va a pasar cuando haga cambios al Gemfile en dos ramas a la vez.

git checkout HEAD -- Gemfile.lock

Esto es para traerme el Gemfile.lock que había antes de obtener mi conflicto. Lo importante es que podemos confirmar con un git status que se preserva el Gemfile, así que los cambios en las versiones o librerías siguen ahí.

Si he metido o quitado una dependencia del Gemfile, ahora ejecuto bundle para que se descargue o se retire del lock por encima de la última versión que había en la rama en la que estoy intentando hacer el merge.

Si he actualizado la versión de una dependencia del Gemfile, ahora ejecuto bundle update para que se vuelva a reflejar ese cambio en el lock por encima de la última versión que había en la rama en la que estoy intentando hacer el merge.

Organizar los e-mails de GitHub

Minientrada

Pude poner orden hoy en la carpeta de archivo en la que normalmente vuelco todos los e-mails de notificaciones de GitHub una vez los he procesado, y que estaba empezando a acumular un tamaño no poco considerable. (Sobre por qué archivo todo en vez de eliminar algunos tipos de notificaciones, es otro asunto.)

En las notificaciones que tienen que ver con un repositorio (como un issue, un PR o una release), GitHub rellena la cabecera List-Id con el identificador del repositorio del que procede. List-Id es una cabecera estandar que la mayoría de clientes de correo usa para reconocer listas. En el caso de GitHub, la List-Id de un repositorio es <repo>.<user>.github.com.

De modo que con un poco de análisis, he podido organizar automáticamente por carpetas todas las notificaciones, para que las notificaciones de makigas/clank (cuya List-Id será clank.makigas.github.com) vayan a Archivo/github.com/makigas/clank, o las del repositorio danirod/rectball vayan a Archivo/github.com/danirod/rectball.

Un par de filtros automáticos se van a asegurar de que futuras notificaciones vayan directamente a esas carpetas, ya que normalmente las notificaciones llegan en momentos en los que no les puedo dedicar tiempo y luego es complicado escarbar mi bandeja de correo para localizar todos estos correos cuando sí tengo tiempo de ponerme con ello.