💾 Archived View for hispagatos.org › post › git-send-mail › index.gmi captured on 2022-06-03 at 23:20:14. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
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.
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.
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"
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.
Buscando buscando encontré esto, gitcredentials [1], me quedé con "credential.helper" en el apartado de Helpers customizados [2]
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
Para aprender más sobre PASS o GOPASS recomiendo leer la página principal de gopass [3]
También hace tiempo hicimos un tutorial de como instalar Neomutt con GPG [4] 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 [5]
disponible en la AUR de Arch GNU/Linux.
paru -S aur/hydroxide
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 del último commit en la rama actual:
git send-email -1
Enviando otro commit:
git send-email -1
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.
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
La etiqueta "[PATCH]" predeterminada se puede cambiar con --subject-prefix.
Ejemplo:
git send-email -1 --subject-prefix = "PATCH cookiertfm"
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.
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.
ReK2 Mucho amor y lucha.
Revisado y actualizado por Harlock [16]
[1] gitcredentials (https://git-scm.com/docs/gitcredentials)
[2] Helpers customizados (https://git-scm.com/docs/gitcredentials#_custom_helpers)
[3] gopass (https://www.gopass.pw/)
[4] Neomutt con GPG (https://hispagatos.org/post/neomutt-gpg-howto-traduccion/)
[5] hydroxide (https://github.com/emersion/hydroxide)
[7] aerc (https://aerc-mail.org/)
[10] Mailing lists vs Github (https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html)
[11] git-send-email (https://git-scm.com/docs/git-send-email)
[13] configuration tool for email + git (https://git-send-email.io/)
[14] gemini://rek2.hispagatos.org (gemini://rek2.hispagatos.org)
[15] gemini://blog.hispagatos.org (gemini://blog.hispagatos.org)
[16] Harlock (gemini://harlock.hispagatos.org)
[17] gemini://harlock.hispagatos.org (gemini://harlock.hispagatos.org)
El hacking NO es un crimen: <no value>
Libertad del software es descentralizar el poder: <no value>
Hackernol Novedades: <no value>
---
→ Older: Help support Hispagatos by mining v2
█████ █████ █████ █████ █████ █████ █████ █████ ░░░░░ ░░░░░ ░░░░░ ░░░░░ ░░░░░ ░░░░░ ░░░░░ ░░░░░
Hispagatos is an Anarcho Hacker collective[1] that resolves around the Hacker ethic[2] of Steven levy and Libertarian Socialism ideas.
We work hard to preserve hacker culture, decentralization,security and privacy in cyberspace and also motivate towards an horizontal and non hierarchical techno-anarcho-communist society (TACS) where technology is made by people for the people not by corporate masters to control people. a(A)a
[donate using LiberaPay](https://liberapay.com/Hispagatos/donate)