Git:git send-email
Inhaltsverzeichnis
Patch(es) mit Git versenden
Git kann ohne extra Aufruf eines Mailprogrammes Patches versenden. Dazu dient der Befehl git send-email [Parameter]
. Dies ist sehr praktisch da man nicht extra einen Mailclient öffnen muss oder kann (z.B. wenn man Remote auf einem PC/Server arbeitet). Voraussetzung ist natürlich das der PC einen Zugang zum Internet hat. In größeren Projekten ist das der übliche Weg und einzig akzeptierte Weg um seine Veränderungsvorschläge zu publizieren.
Paketabhängigkeiten
git send-email
benötigt zusätzliche Software die eventuell nicht automatisch durch die Paketverwaltungssoftware aufgelöst wird. Benötigt wird ein MTA (Mail Transfer Agent). Da stehen dann mehrere zur Auswahl (Postfix, Sendmail, Exim, ...). Benutzt den mit dem Ihr gegebenenfalls schon arbeitet oder installiert den favorisierten MTA nach.
Optional nachinstallieren falls nicht schon ein MTA installiert ist
$ sudo apt-get install <Euer favorisierter MTA> # nur einen dieser installieren! sendmail, postfix oder exim
Zusätzlich müssen folgende Pakete nachinstalliert werden:
$ sudo apt-get install git-email libnet-smtp-ssl-perl libauthen-sasl-perl\
libnet-perl libio-socket-ssl-perl libmime-tools-perl
manuelle Vorgehensweise
Zum Testen oder gezielten Übergehen von Einstellungen kann man alle Parameter des Git Befehls von Hand angeben. Damit git einen oder mehrere Patches versenden kann müssen die Parameter für den E-Mail Versand angebenden werden.
git send-email
<Patch>
--from <Name>
am besten mir Realname, Nickname ist nicht überall gerne gesehen (optional)--to <E-Mail Adresse>
Zieladresse, z.B. eine Mailingliste--smtp-server <Server Adresse>
die SMTP Serveradresse deines Providers--smtp-server-port <Portadresse>
der Zielport vom SMTP Server--smtp-user <Benutzer>
ohne @TLD!--smpt-pass <Passwort>
Dein Passwort bei Deinem Emailprovider--smtp-encyption=<Encryption>
in Kleinbuchstaben
Beispiel für GMail:
$ git send-email 0001-ChangeLog-adding-entry.patch --to ml_neutron@projekt.com --from "Karl Klammer" \
--smtp-server smtp.gmail.com --smtp-server-port 587 --smtp-user karl.klammer \
--smtp-pass super_geheim --smtp-encryption=tls
statische Einträge in der Konfigdatei von Git
Man kann alles diese Angaben in die Konfigdatei .git/config
eintragen. Damit minimiert sich der Aufruf des Git Befehls auf git send-email <Patch>
.
Wenn man Patche z.B. immer an die selbe Adresse verschickt (z.B. an eine Mailingliste) dann empfiehlt es sich die nötigen Parameter in die Konfigdatei des Projektes einzutragen.
z.B. für GMail:
[sendemail]
to = ml_neutron@projekt.com
from = "<Euer Name>"
smtpencryption = tls
smtpserver = smtp.gmail.com
smtpserverport = 587
smtpuser = <Benutzer> # alles vor @gmail.com , nicht die komplette E-Mailadresse!!!
smtppass = <Passwort>
confirm = never
und für T-Online:
[sendemail]
to = ml_neutron@projekt.com
from = "<Euer Name>"
smtpserver = smtpmail.t-online.de
smtpserverport = 25
smtpuser = <Benutzer> # alles vor @t-online.de , nicht die komplette E-Mailadresse!!!
smtppass = <Passwort>
confirm = never
Probleme
Sollten Ihr beim Versenden per git send-email
folgende Fehlermeldung erhalten:
...
X-Mailer: git-send-email 1.7.2.5
Result: 250 2.0.0 Message accepted.
In git 1.7.0, the default has changed to --no-chain-reply-to
Set sendemail.chainreplyto configuration variable to true if
you want to keep --chain-reply-to as your default.
Dann könnt Ihr mit git config sendemail.chainreplyto false
folgenden Eintrag zu .git/config
hinzufügen.
[sendemail]
...
chainreplyto = false
...
Damit weiß Git bei jedem Benutzen von git send-email
das nicht "in Reply to" erfolgt. Dies ist immer dann der Fall wenn man einen Patch das erste Mal an einen Empfänger sendet. Das Gegenteil tritt natürlich dann ein wenn Ihr auf einen Patch mit einer anderen Version antwortet. Dies dürfte aber relativ selten vorkommen und kann dann wieder explizit beim Aufruf von git send-email
mit --chain-reply-to <ID/Betreff der Mail>
angegeben werden.
Tips
- Bevor Ihr Patches an eine Mailingliste verschicken wollt prüft zuvor ob alles "perfekt" ist.
- Je nach Größe der Teilnehmer auf einer Mailingliste kann es etwas anstrengend sein, allen begreiflich zu machen das der oder die Patche doch nicht richtig waren. Dies könnt Ihr recht einfach prüfen indem Ihr eben nicht an die ML verschickt sondern an Euch selbst. (Mit der Option
--to adresse@provider.tld
könnt Ihr den Eintrag in der .git/config übergehen oder man richtet sich einen Alias ein der einem die viele Tipparbeit abnimmt.)
- Je nach Größe der Teilnehmer auf einer Mailingliste kann es etwas anstrengend sein, allen begreiflich zu machen das der oder die Patche doch nicht richtig waren. Dies könnt Ihr recht einfach prüfen indem Ihr eben nicht an die ML verschickt sondern an Euch selbst. (Mit der Option
- Jeder Patch sollte ein "signed-off" besitzen!
- Damit kann man später immer noch herausfinden von wem der ursprüngliche Patch/Code/Gedanke war. Bedenkt das Git ein dezentrales Versionsverwaltungssystem ist und nicht jeder der etwas zu einem Projekt beitragen will muss automatisch CheckIn Berechtigungen zu einem Repository besitzen.
- Jeder weitergeleitete und schon geprüfte Patch kann zusätzlich ein "signed-off-by-cc" beinhalten.
- Wenn der Ersteller des Patches diesen nicht mit Git erstellt hat oder kann kann man auch noch ein "reported-by" hinzufügen. Damit wissen die Developer das dieser Patch schon geprüft ist und können diesen in der Regel direkt ins Repo commiten.
- Nur ein Patch pro Mail!
- Sendet pro Mail nur einen Patch, dies erleichtert die Arbeit derer die diese Patche commiten. Wollt Ihr mehrere Patche versenden benutzt z.B. ein Shellscript was pro Patch
git send-email
aufruft. Einfacher ist jedoch der Parameter--compose
. Mit diesem kann man eine "einleitende" Mail verfassen (dies ist aber auf der Kernelmailingliste z.B. verpönt, also vorher prüfen ob das erwünscht ist). Wenn Ihr mehrere Patche habt die thematisch zusammen gehören dann solltet Ihr diese dann damit kombinieren. - Ein Beispiel:
- Sendet pro Mail nur einen Patch, dies erleichtert die Arbeit derer die diese Patche commiten. Wollt Ihr mehrere Patche versenden benutzt z.B. ein Shellscript was pro Patch
$ git send-email 000*.patch --compose
- Es öffnet sich der verknüpfte Editor (siehe auch alternativer Editor) zum Arbeiten mit git. Zu sehen sind ein paar Erläuterungen und Hilfestellungen und das Grundgerüst für die erste Mail. (Hinweis: <Hier müsst Ihr was eintragen> <Hier hat Git schon etwas eingetragen>)
1 From <Euer Name> # This line is ignored. 2 GIT: Lines beginning in "GIT:" will be removed. 3 GIT: Consider including an overall diffstat or table of contents 4 GIT: for the patch you are writing. 5 GIT: 6 GIT: Clear the body content if you don't wish to send a summary. 7 From: <Euer Name> 8 Subject: <Hier kommt der Betreff für die "einleitende" Mail hin> 9 In-Reply-To: 10 11 GIT: [PATCH 1/2] libcoolstream-mt: Modified BS to use the libcoolstream-mt 12 GIT: [PATCH 2/2] beta-2.6.26.8-nevis: new drivers required by libcoolstream-mt 13 <hier kommt der Text der Mail hin> 14 <es darf ruhig etwas ausführlicher erklärt werden um was es geht> 15 16 <gerne auch mit mehreren Absätzen>
- Macht neuere Versionen eines/mehrerer Patches kenntlich!
- Es ist keine Schande neuere Versionen eines Patches zu schicken. Schlieslich kann ja noch nachträglich etwas aufgefallen sein was eine weitere Version eines Patches nötig machte. Allerdings sollten die Teammitglieder sofort erkennen das es sich um eine neuere Version handelt. Beim Erstellen des Patches kann dies mit
git format-patch --subject-prefix="PATCH v[x]"
erreicht werden. - In der Mail sollte ein "Changelog" zu finden sein worin steht was sich gegenüber der Vorgängerversion des Patches geändert hat. Weitere Hinweise sind unter [1] zu finden.
- Es ist keine Schande neuere Versionen eines Patches zu schicken. Schlieslich kann ja noch nachträglich etwas aufgefallen sein was eine weitere Version eines Patches nötig machte. Allerdings sollten die Teammitglieder sofort erkennen das es sich um eine neuere Version handelt. Beim Erstellen des Patches kann dies mit