Esta página esta siendo tocada. Disculpa si las cosas no se ven como siempre.

Etiqueta: git

  • La clave pública GPG que había subida a mi página de contacto caducaba mañana. Esta clave la uso fundamentalmente para firmar releases en GitHub y otras plataformas, aunque alguna vez he recibido correo firmado y alguna vez hasta correo cifrado.

    El mes pasado extendí el periodo de validez por un par de años más pero olvidé actualizar también la subclave de cifrado. Hoy he extendido la fecha de validez y he subido una versión actualizada de la clave. No termino de comprender cómo funciona un keyserver, o si la actualización verdaderamente es efectiva, o qué pasa con las versiones antiguas de la clave, pero en principio he testeado el archivo que hay subido en https://danirod.es/contact/pgp.asc desde otro ordenador y todo está funcionando, así que bien.

  • 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.

  • 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.

  • 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.

  • 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.