Cómo usar GIT send-email⌗

Seamos claros, github nos ha mal educado a muchos usando herramientas de web/UI para compartir parches en nuestros proyectos libres. En realidad git fué desarrollado de manera descentralizada para usarse por medio de smtp sin tener que pasar por una web central. Hay una razón muy clara por la que el kernel “Linux” usa git por medio de listas de correo con smtp y es que Git viene con herramientas integradas para colaborar por correo electrónico. Con esta guía contribuirás a proyectos impulsados por email como el kernel de Linux, PostgreSQL o incluso el mismo git en muy poco tiempo.

Instalación de GIT send-email⌗

Es probable que ya tengas instalado Git pero eso no significa que automáticamente Git sepa como y por donde mandar los parches. Puedes verificar si el correo electrónico de envío está disponible ejecutando;

git send-email --help

Si muestra el man page bien lo tienes instalado si no debes instalar el git send-email.

Configuración de tu nombre y dirección de correo electrónico:⌗

Debes decirle a Git tu nombre y dirección de correo electrónico, probablemente lo hayas hecho ya en caso contrario ejecuta estos comandos:

git config --global user.name "mi nombre"
git config --global user.email "myemail@example.com"

Configuración de las opciones de envío de correo⌗

Git send-email envía los correos electrónicos a través de un servidor SMTP por lo que debes configurar los parámetros del servidor. Consulta la documentación del proveedor de tu correo electrónico para encontrar los parámetros correctos. Así es como dejaría mi configuración de correo:

git config --global sendemail.smtpencryption tls
git config --global sendemail.smtpserver mail.hispagatos.org
git config --global sendemail.smtpuser rek2@hispagatos.org
git config --global sendemail.smtpserverport 587
git config --global sendemail.smtppass "AQUI VAMOS A USAR GOPASS/PASS"

Como almacenar la contraseña en el archivo de configuración GIT obviamente es un riesgo de seguridad vamos a usar GOPASS. No es obligatorio configurar la contraseña, si no está configurado Git send-email te preguntará cada vez que se use el comando, vamos lo que se dice una lamerada.

Configurar gopass/git send-email⌗

Buscando buscando encontré esto, gitcredentials, me quedé con “credential.helper” en el apartado de Helpers customizados

Un poco de kung-fu Linux y salió el siguiente comando, si no lo entendéis RTFM el man page y los enlaces que os he puesto arriba.

credential.helper=!f() { echo "password=$(gopass show -o -f email/cfernandez@protonmail.ch)"; }; f

Herramientas necesarias⌗

Para aprender más sobre PASS o GOPASS recomiendo leer la página principal de gopass También hace tiempo hicimos un tutorial de como instalar Neomutt con GPG donde usamos pass, compatible con gopass, para instalar en Arch GNU/Linux.

paru -S community/gopass

Si tenéis protonmail podéis usar en vez de su proxy oficial que es una mierda, una alternativa llamada hydroxide disponible en la AUR de Arch GNU/Linux.

paru -S aur/hydroxide

Como mandar parches usando git send-email⌗

Recomiendo que RTFM el manual con:

git send-email --help

Pero de todas formas aquí van unos consejos.

Para no incluirnos a nosotros mismos en el correo que se envía a toda la lista podemos suprimirlo con:

git config --global sendemail.suppresscc self

Envío de un solo parche⌗

Envío del último commit en la rama actual:

git send-email -1

Enviando otro commit:

git send-email -1 <referencia del commit>

Envío de varios parches⌗

Envío de los últimos 10 commits en la rama actual:

git send-email -10 --cover-letter --annotate

La opción –cover-letter crea un correo adicional que se enviará antes de los correos del parche, a modo de “carta de presentación”. Puedes escribir una introducción del conjunto de parches en dicho correo. Si necesitas explicar los parches asegúrate de incluir las explicaciones también en los mensajes de confirmación porque el texto de la “carta de presentación” no se registrará en el historial de git. Si no crees que sea necesaria ninguna introducción o explicación está bien con sólo el shortlog que se incluye en la cover-letter de forma predeterminada, sólo pon algo sensato en el encabezado del “Asunto”.

La opción –annotate hace que se inicie un editor para cada uno de los correos ,lo que te permite editar los correos. La opción siempre es necesaria para editar el encabezado del “Asunto” en la carta de presentación.

Agregar información sobre la versión del parche⌗

Por defecto en los correos electrónicos del parche pondrá “[PATCH]” en el asunto, (o “[PATCH n / m]” donde n es el número de secuencia del parche y m es el número total de parches dentro del conjunto de parches), para que al enviar versiones actualizadas de parches se indique la versión “[PATCH v2]” o “[PATCH v2 n / m]”. Para hacer esto usa la opción -v. Aquí hay un ejemplo, (es posible que quieras agregar –annotate para agregar notas al parche sobre lo que cambió en la nueva versión):

git enviar-correo electrónico -v2 -1

Cambiar o corregir la etiqueta [PATCH] en el asunto⌗

La etiqueta “[PATCH]” predeterminada se puede cambiar con –subject-prefix.

Ejemplo:

  • Usar “[PATCH proyecto-destino]” como etiqueta es una buena forma de indicar que el parche está destinado al proyecto-destino.
git send-email -1 --subject-prefix = "PATCH cookiertfm"

Agregar notas adicionales a los correos electrónicos de parches⌗

A veces es conveniente anotar en los parches algunos comentarios que no deben incluirse en el mensaje de confirmación. Por ejemplo uno podría querer escribir “No estoy seguro si esto debería confirmarse todavía porque …” en un parche, pero el texto no tiene sentido en el mensaje de confirmación. Estas notas se pueden escribir debajo de los tres guiones “—” que se encuentran en cada parche, después del mensaje de confirmación. Usa la opción –annotate con git send-email para poder editar los correos antes de que se envíen.

Formatear y enviar en dos pasos⌗

En lugar de usar la opción –annotate se puede ejecutar primero “git format-patch” para crear archivos de texto (usa la opción -o para seleccionar un directorio donde se almacenarán). Estos archivos se pueden inspeccionar y editar para después ya usar “git send-email” (sin la opción -1) para enviarlos.

Bueno espero que esto os ayude a empezar a usar git con email y dejar de darle “hits” “page hits” y “visitas a la propaganda del sitio” cuando usáis la web.

  • recomiendo que instaleis git en vuestro propio servidor de no ser así usad el de sourcehut.
  • recomiendo como cliente de email a aerc

Más lectura:⌗

Referencias:⌗

ReK2 Mucho amor y lucha.

Revisado y actualizado por Harlock

  • gemini://harlock.hispagatos.org
  • matrix: @harlock:hispagatos.org
  • mastodon: @harlock@hispagatos.space