English ▾ Themen ▾ Neueste Version ▾ git-send-email zuletzt aktualisiert in 2.52.0

NAME

git-send-email - Eine Sammlung von Patches als E-Mails senden

SYNOPSIS

git send-email [<options>] (<file>|<directory>)…​
git send-email [<options>] <format-patch-options>
git send-email --dump-aliases
git send-email --translate-aliases

BESCHREIBUNG

Nimmt die auf der Kommandozeile übergebenen Patches entgegen und versendet sie per E-Mail. Patches können als Dateien, Verzeichnisse (die alle Dateien im Verzeichnis versenden) oder direkt als Revisionsliste angegeben werden. Im letzteren Fall kann jedes Format, das von git-format-patch[1] akzeptiert wird, an git send-email übergeben werden, ebenso wie Optionen, die von git-format-patch[1] verstanden werden.

Der Kopf der E-Mail ist über Kommandozeilenoptionen konfigurierbar. Wenn nicht auf der Kommandozeile angegeben, wird der Benutzer über eine ReadLine-fähige Schnittstelle aufgefordert, die notwendigen Informationen bereitzustellen.

Für Patchdateien werden zwei Formate akzeptiert

  1. mbox-Formatdateien

    Dies ist das, was git-format-patch[1] erzeugt. Die meisten Header und MIME-Formatierungen werden ignoriert.

  2. Das ursprüngliche Format, das von Greg Kroah-Hartmans Skript send_lots_of_email.pl verwendet wurde

    Dieses Format erwartet, dass die erste Zeile der Datei den Cc:-Wert und die zweite Zeile den Betreff: der Nachricht enthält.

OPTIONEN

Zusammenstellen

--annotate

Jeden Patch, den Sie senden möchten, überprüfen und bearbeiten. Standard ist der Wert von sendemail.annotate. Siehe den Abschnitt KONFIGURATION für sendemail.multiEdit.

--bcc=<adresse>,…

Geben Sie für jede E-Mail einen Bcc:-Wert an. Standard ist der Wert von sendemail.bcc.

Diese Option kann mehrmals angegeben werden.

--cc=<adresse>,…

Geben Sie für jede E-Mail einen Startwert für Cc: an. Standard ist der Wert von sendemail.cc.

Diese Option kann mehrmals angegeben werden.

--compose

Ruft einen Texteditor auf (siehe GIT_EDITOR in git-var[1]), um eine einleitende Nachricht für die Patch-Serie zu bearbeiten.

Wenn --compose verwendet wird, verwendet git send-email die in der Nachricht angegebenen Header From, To, Cc, Bcc, Betreff, Reply-To und In-Reply-To. Wenn der Nachrichtentext (was Sie nach den Headern und einer Leerzeile eingeben) nur Leerzeilen (oder mit Git: beginnende) enthält, wird die Zusammenfassung nicht gesendet, aber die oben genannten Header werden verwendet, es sei denn, sie werden entfernt.

Fehlende From- oder In-Reply-To-Header werden abgefragt.

Siehe den Abschnitt KONFIGURATION für sendemail.multiEdit.

--from=<adresse>

Geben Sie den Absender der E-Mails an. Wenn nicht auf der Kommandozeile angegeben, wird der Wert der Konfigurationsoption sendemail.from verwendet. Wenn weder die Kommandozeilenoption noch sendemail.from gesetzt sind, wird der Benutzer nach dem Wert gefragt. Der Standardwert für die Abfrage ist der Wert von GIT_AUTHOR_IDENT oder GIT_COMMITTER_IDENT, wenn dieser nicht gesetzt ist, wie er von git var -l zurückgegeben wird.

--reply-to=<adresse>

Geben Sie die Adresse an, an die Antworten von Empfängern gesendet werden sollen. Verwenden Sie dies, wenn Antworten auf Nachrichten an eine andere Adresse gehen sollen als die mit dem Parameter --from angegebene.

--in-reply-to=<identifikator>

Lassen Sie die erste E-Mail (oder alle E-Mails mit --no-thread) als Antwort auf die angegebene Message-ID erscheinen, was das Durchbrechen von Threads vermeidet, um eine neue Patch-Serie bereitzustellen. Die zweite und nachfolgende E-Mails werden gemäß der Einstellung --[no-]chain-reply-to als Antworten gesendet.

Wenn also beispielsweise --thread und --no-chain-reply-to angegeben sind, antworten die zweite und nachfolgende Patches auf die erste, wie in der folgenden Abbildung, wo [PATCH v2 0/3] eine Antwort auf [PATCH 0/2] ist.

[PATCH 0/2] Here is what I did...
  [PATCH 1/2] Clean up and tests
  [PATCH 2/2] Implementation
  [PATCH v2 0/3] Here is a reroll
    [PATCH v2 1/3] Clean up
    [PATCH v2 2/3] New tests
    [PATCH v2 3/3] Implementation

Nur notwendig, wenn auch --compose gesetzt ist. Wenn --compose nicht gesetzt ist, wird dies abgefragt.

--outlook-id-fix
--no-outlook-id-fix

Microsoft Outlook SMTP-Server verwerfen die per E-Mail gesendete Message-ID und weisen eine neue zufällige Message-ID zu, wodurch Threads unterbrochen werden.

Mit --outlook-id-fix verwendet git send-email einen Outlook-spezifischen Mechanismus, um die vom Server zugewiesene Message-ID zu erfahren und den Thread zu reparieren. Verwenden Sie ihn nur, wenn Sie wissen, dass der Server die neu geschriebene Message-ID genauso meldet wie Outlook-Server.

Ohne diese Option wird die Korrektur standardmäßig durchgeführt, wenn mit smtp.office365.com oder smtp-mail.outlook.com gesprochen wird. Verwenden Sie --no-outlook-id-fix, um sie auch bei der Kommunikation mit diesen beiden Servern zu deaktivieren.

--subject=<zeichenkette>

Geben Sie den Anfangsbetreff des E-Mail-Threads an. Nur notwendig, wenn auch --compose gesetzt ist. Wenn --compose nicht gesetzt ist, wird dies abgefragt.

--to=<adresse>,…

Geben Sie den primären Empfänger der generierten E-Mails an. Dies ist in der Regel der Upstream-Maintainer des beteiligten Projekts. Standard ist der Wert des Konfigurationswerts sendemail.to; wenn dieser nicht angegeben ist und --to-cmd nicht angegeben ist, wird dies abgefragt.

Diese Option kann mehrmals angegeben werden.

--8bit-encoding=<codierung>

Wenn eine Nachricht oder ein Betreff nicht im ASCII-Format vorliegt und seine Kodierung nicht deklariert, werden Header/Anführungszeichen hinzugefügt, um anzuzeigen, dass er in <Codierung> kodiert ist. Standard ist der Wert von sendemail.assume8bitEncoding; wenn dieser nicht angegeben ist, wird dies abgefragt, wenn Nicht-ASCII-Dateien angetroffen werden.

Beachten Sie, dass keinerlei Versuche unternommen werden, die Kodierung zu validieren.

--compose-encoding=<codierung>

Geben Sie die Kodierung der Nachricht an. Standard ist der Wert von sendemail.composeEncoding; wenn dieser nicht angegeben ist, wird UTF-8 angenommen.

--transfer-encoding=(7bit|8bit|quoted-printable|base64|auto)

Geben Sie die Transferkodierung an, die zum Senden der Nachricht über SMTP verwendet werden soll. 7bit schlägt fehl, wenn eine Nicht-ASCII-Nachricht angetroffen wird. quoted-printable kann nützlich sein, wenn das Repository Dateien enthält, die Wagenrückläufe enthalten, macht aber die rohe Patch-E-Mail-Datei (wie aus einem MUA gespeichert) manuell schwerer zu überprüfen. base64 ist noch narrensicherer, aber auch noch undurchsichtiger. auto verwendet 8bit, wenn möglich, und andernfalls quoted-printable.

Standard ist der Wert des Konfigurationswerts sendemail.transferEncoding; wenn dieser nicht angegeben ist, wird standardmäßig auto verwendet.

--xmailer
--no-xmailer

Fügt den Header X-Mailer: hinzu (oder verhindert das Hinzufügen). Standardmäßig wird der Header hinzugefügt, er kann aber deaktiviert werden, indem die Konfigurationsvariable sendemail.xmailer auf false gesetzt wird.

Senden

--envelope-sender=<adresse>

Geben Sie den Envelope-Sender an, der zum Senden der E-Mails verwendet wird. Dies ist nützlich, wenn Ihre Standardadresse nicht die Adresse ist, die in einer Mailingliste abonniert ist. Um die From-Adresse zu verwenden, setzen Sie den Wert auf auto. Wenn Sie das Skript sendmail verwenden, benötigen Sie entsprechende Berechtigungen für den Parameter -f. Standard ist der Wert der Konfigurationsvariable sendemail.envelopeSender; wenn diese nicht angegeben ist, überlässt die Auswahl des Envelope-Senders Ihrem MTA.

--sendmail-cmd=<Befehl>

Geben Sie einen Befehl an, der zum Senden der E-Mail ausgeführt werden soll. Der Befehl sollte sendmail-ähnlich sein; insbesondere muss er die Option -i unterstützen. Der Befehl wird bei Bedarf in der Shell ausgeführt. Standard ist der Wert von sendemail.sendmailCmd. Wenn nicht angegeben und wenn auch --smtp-server nicht angegeben ist, sucht git send-email nach sendmail in /usr/sbin, /usr/lib und $PATH.

--smtp-encryption=<verschlüsselung>

Geben Sie an, auf welche Weise die Verschlüsselung für die SMTP-Verbindung beginnt. Gültige Werte sind ssl und tls. Jeder andere Wert kehrt zu unverschlüsseltem SMTP zurück, der standardmäßig Port 25 verwendet. Trotz der Namen verwenden beide Werte die gleiche neuere Version von TLS, aber aus historischen Gründen haben sie diese Namen. ssl bezieht sich auf die "implizite" Verschlüsselung (manchmal SMTPS genannt), die standardmäßig Port 465 verwendet. tls bezieht sich auf die "explizite" Verschlüsselung (oft als STARTTLS bekannt), die standardmäßig Port 25 verwendet. Andere Ports können vom SMTP-Server verwendet werden, die nicht die Standardports sind. Üblicherweise gefundene alternative Ports für tls und unverschlüsselt sind 587. Sie müssen die Dokumentation Ihres Anbieters oder Ihre Serverkonfiguration prüfen, um sicherzugehen. Standard ist der Wert von sendemail.smtpEncryption.

--smtp-domain=<FQDN>

Gibt den Fully Qualified Domain Name (FQDN) an, der im HELO/EHLO-Befehl an den SMTP-Server gesendet wird. Einige Server verlangen, dass der FQDN mit Ihrer IP-Adresse übereinstimmt. Wenn nicht gesetzt, versucht git send-email, Ihren FQDN automatisch zu ermitteln. Standard ist der Wert von sendemail.smtpDomain.

--smtp-auth=<mechanismen>

Leerzeichen-getrennte Liste der erlaubten SMTP-AUTH-Mechanismen. Diese Einstellung erzwingt die Verwendung nur der aufgeführten Mechanismen. Beispiel

$ git send-email --smtp-auth="PLAIN LOGIN GSSAPI" ...

Wenn mindestens einer der angegebenen Mechanismen mit denen übereinstimmt, die vom SMTP-Server beworben werden, und wenn er von der verwendeten SASL-Bibliothek unterstützt wird, wird der Mechanismus zur Authentifizierung verwendet. Wenn weder sendemail.smtpAuth noch --smtp-auth angegeben sind, können alle von der SASL-Bibliothek unterstützten Mechanismen verwendet werden. Der spezielle Wert none kann angegeben werden, um die Authentifizierung unabhängig von --smtp-user vollständig zu deaktivieren.

--smtp-pass[=<passwort>]

Passwort für SMTP-AUTH. Das Argument ist optional: Wenn kein Argument angegeben wird, wird die leere Zeichenkette als Passwort verwendet. Standard ist der Wert von sendemail.smtpPass, jedoch überschreibt --smtp-pass diesen Wert immer.

Darüber hinaus müssen Passwörter nicht in Konfigurationsdateien oder auf der Kommandozeile angegeben werden. Wenn ein Benutzername angegeben wurde (mit --smtp-user oder einer sendemail.smtpUser), aber kein Passwort angegeben wurde (mit --smtp-pass oder sendemail.smtpPass), wird das Passwort über git-credential[1] bezogen.

--no-smtp-auth

Deaktiviert die SMTP-Authentifizierung. Kurzform für --smtp-auth=none.

--smtp-server=<host>

Wenn gesetzt, gibt den ausgehenden SMTP-Server an, der verwendet werden soll (z. B. smtp.example.com oder eine rohe IP-Adresse). Wenn nicht angegeben und wenn auch --sendmail-cmd nicht angegeben ist, wird standardmäßig nach sendmail in /usr/sbin, /usr/lib und $PATH gesucht, falls ein solches Programm verfügbar ist, andernfalls wird auf localhost zurückgegriffen.

Aus Gründen der Abwärtskompatibilität kann diese Option auch einen vollständigen Pfad zu einem sendmail-ähnlichen Programm angeben; das Programm muss die Option -i unterstützen. Diese Methode unterstützt nicht das Übergeben von Argumenten oder die Verwendung von einfachen Befehlsnamen. Für diese Anwendungsfälle sollten Sie stattdessen --sendmail-cmd verwenden.

--smtp-server-port=<port>

Gibt einen anderen Port als den Standardport an (SMTP-Server lauschen typischerweise auf Port 25, können aber auch auf Port 587 für Submission oder Port 465 für SSL lauschen); symbolische Portnamen (z. B. submission statt 587) werden ebenfalls akzeptiert. Der Port kann auch mit der Konfigurationsvariable sendemail.smtpServerPort gesetzt werden.

--smtp-server-option=<option>

Wenn gesetzt, gibt die Option des ausgehenden SMTP-Servers an, die verwendet werden soll. Der Standardwert kann durch die Konfigurationsoption sendemail.smtpServerOption angegeben werden.

Die Option --smtp-server-option muss für jede Option wiederholt werden, die Sie an den Server übergeben möchten. Ebenso müssen für jede Option unterschiedliche Zeilen in den Konfigurationsdateien verwendet werden.

--smtp-ssl

Legacy-Alias für --smtp-encryption ssl.

--smtp-ssl-cert-path

Pfad zu einem Speicher vertrauenswürdiger CA-Zertifikate für die SMTP-SSL/TLS-Zertifikatsvalidierung (entweder ein Verzeichnis, das von c_rehash verarbeitet wurde, oder eine einzelne Datei, die ein oder mehrere PEM-formatierte Zertifikate enthält, die verkettet sind: siehe die Beschreibung der Optionen -CAfile <datei> und -CApath <verzeichnis> von https://docs.openssl.org/master/man1/openssl-verify/ [OpenSSL's verify(1) Handbuchseite] für weitere Informationen). Setzen Sie ihn auf eine leere Zeichenkette, um die Zertifikatsvalidierung zu deaktivieren. Standard ist der Wert der Konfigurationsvariable sendemail.smtpSSLCertPath, falls gesetzt, andernfalls die standardmäßig in der verwendeten SSL-Bibliothek integrierte Einstellung (was auf den meisten Plattformen die beste Wahl sein sollte).

--smtp-user=<benutzer>

Benutzername für SMTP-AUTH. Standard ist der Wert von sendemail.smtpUser; wenn kein Benutzername angegeben wird (mit --smtp-user oder sendemail.smtpUser), wird keine Authentifizierung versucht.

--smtp-debug=(0|1)

Debug-Ausgabe aktivieren (1) oder deaktivieren (0). Wenn aktiviert, werden SMTP-Befehle und Antworten ausgegeben. Nützlich zum Debuggen von TLS-Verbindungen und Authentifizierungsproblemen.

--imap-sent-folder=<ordner>

Einige E-Mail-Anbieter (z. B. iCloud) senden keine Kopie der per SMTP gesendeten E-Mails in den Ordner Gesendet oder ähnliche Ordner in Ihrem Postfach. Verwenden Sie diese Option, um git imap-send zu verwenden, um eine Kopie der E-Mails in den mit dieser Option angegebenen Ordner zu senden. Sie können git imap-send --list ausführen, um eine Liste gültiger Ordnernamen zu erhalten, einschließlich des korrekten Namens des Ordners Gesendet in Ihrem Postfach. Sie können diese Option auch verwenden, um E-Mails in einen dedizierten IMAP-Ordner Ihrer Wahl zu senden.

Diese Funktion erfordert die Einrichtung von git imap-send. Weitere Informationen finden Sie unter git-imap-send[1].

--use-imap-only
--no-use-imap-only

Wenn dies gesetzt ist, werden alle E-Mails nur in den mit --imap-sent-folder oder sendemail.imapSentFolder angegebenen IMAP-Ordner kopiert und nicht an die Empfänger gesendet. Nützlich, wenn Sie nur einen Entwurf der E-Mails erstellen und einen anderen E-Mail-Client zum Senden verwenden möchten. Wenn mit --no-use-imap-only deaktiviert, werden die E-Mails wie gewohnt gesendet. Standardmäßig deaktiviert, aber die Konfigurationsvariable sendemail.useImapOnly kann verwendet werden, um sie zu aktivieren.

Diese Funktion erfordert die Einrichtung von git imap-send. Weitere Informationen finden Sie unter git-imap-send[1].

--batch-size=<num>

Einige E-Mail-Server (z. B. smtp.163.com) beschränken die Anzahl der E-Mails, die pro Sitzung (Verbindung) gesendet werden können, was zu einem Fehler beim Senden vieler Nachrichten führt. Mit dieser Option trennt sich send-email nach dem Senden von <num> Nachrichten und wartet einige Sekunden (siehe --relogin-delay) und verbindet sich neu, um eine solche Beschränkung zu umgehen. Möglicherweise möchten Sie eine Art von Anmeldeinformationshelfer verwenden, um zu vermeiden, dass Sie Ihr Passwort jedes Mal neu eingeben müssen, wenn dies geschieht. Standard ist die Konfigurationsvariable sendemail.smtpBatchSize.

--relogin-delay=<int>

Wartet <int> Sekunden, bevor eine erneute Verbindung zum SMTP-Server hergestellt wird. Wird zusammen mit der Option --batch-size verwendet. Standard ist die Konfigurationsvariable sendemail.smtpReloginDelay.

Automatisierung

--no-to
--no-cc
--no-bcc

Löscht jede Liste von To:, Cc:, Bcc:-Adressen, die zuvor per Konfiguration festgelegt wurden.

--no-identity

Löscht den zuvor gelesenen Wert von sendemail.identity, der über die Konfiguration festgelegt wurde, falls vorhanden.

--to-cmd=<Befehl>

Gibt einen Befehl an, der einmal pro Patch-Datei ausgeführt werden soll und der Patch-Datei-spezifische To:-Einträge generieren soll. Die Ausgabe dieses Befehls muss eine E-Mail-Adresse pro Zeile sein. Standard ist der Wert des Konfigurationswerts sendemail.toCmd.

--cc-cmd=<Befehl>

Gibt einen Befehl an, der einmal pro Patch-Datei ausgeführt werden soll und der Patch-Datei-spezifische Cc:-Einträge generieren soll. Die Ausgabe dieses Befehls muss eine E-Mail-Adresse pro Zeile sein. Standard ist der Wert des Konfigurationswerts sendemail.ccCmd.

--header-cmd=<Befehl>

Gibt einen Befehl an, der einmal pro ausgehender Nachricht ausgeführt wird und RFC 2822-Stil-Headerzeilen ausgibt, die in diese eingefügt werden sollen. Wenn die Konfigurationsvariable sendemail.headerCmd gesetzt ist, wird ihr Wert immer verwendet. Wenn --header-cmd auf der Kommandozeile angegeben wird, hat dessen Wert Vorrang vor der Konfigurationsvariable sendemail.headerCmd.

--no-header-cmd

Deaktiviert jeden verwendeten Header-Befehl.

--chain-reply-to
--no-chain-reply-to

Wenn dies gesetzt ist, wird jede E-Mail als Antwort auf die zuvor gesendete E-Mail gesendet. Wenn mit --no-chain-reply-to deaktiviert, werden alle E-Mails nach der ersten als Antwort auf die erste gesendete E-Mail gesendet. Bei Verwendung dieser Option wird empfohlen, dass die erste angegebene Datei eine Übersicht über die gesamte Patch-Serie ist. Standardmäßig deaktiviert, aber die Konfigurationsvariable sendemail.chainReplyTo kann verwendet werden, um sie zu aktivieren.

--identity=<identität>

Eine Konfigurationsidentität. Wenn angegeben, bewirkt dies, dass Werte im Abschnitt sendemail.<identität> Vorrang vor Werten im Abschnitt sendemail haben. Die Standardidentität ist der Wert von sendemail.identity.

--signed-off-by-cc
--no-signed-off-by-cc

Wenn dies gesetzt ist, werden E-Mail-Adressen, die im Trailer Signed-off-by oder in Cc:-Zeilen gefunden werden, zur CC-Liste hinzugefügt. Standard ist der Wert des Konfigurationswerts sendemail.signedOffByCc; wenn dieser nicht angegeben ist, wird standardmäßig --signed-off-by-cc verwendet.

--cc-cover
--no-cc-cover

Wenn dies gesetzt ist, werden E-Mail-Adressen, die in Cc:-Headern des ersten Patches der Serie (typischerweise das Anschreiben) gefunden werden, zur CC-Liste für jede E-Mail-Einheit hinzugefügt. Standard ist der Wert des Konfigurationswerts sendemail.ccCover; wenn dieser nicht angegeben ist, wird standardmäßig --no-cc-cover verwendet.

--to-cover
--no-to-cover

Wenn dies gesetzt ist, werden E-Mail-Adressen, die in To:-Headern des ersten Patches der Serie (typischerweise das Anschreiben) gefunden werden, zur To-Liste für jede E-Mail-Einheit hinzugefügt. Standard ist der Wert des Konfigurationswerts sendemail.toCover; wenn dieser nicht angegeben ist, wird standardmäßig --no-to-cover verwendet.

--suppress-cc=<kategorie>

Geben Sie eine zusätzliche Kategorie von Empfängern an, die vom automatischen CC unterdrückt werden sollen.

  • author vermeidet die Einbeziehung des Patch-Autors.

  • self vermeidet die Einbeziehung des Absenders.

  • cc vermeidet die Einbeziehung von Personen, die in Cc-Zeilen im Patch-Header genannt werden, außer dem Absender (verwenden Sie self dafür).

  • bodycc vermeidet die Einbeziehung von Personen, die in Cc-Zeilen im Patch-Body (Commit-Nachricht) genannt werden, außer dem Absender (verwenden Sie self dafür).

  • sob vermeidet die Einbeziehung von Personen, die in Signed-off-by-Trailern genannt werden, außer dem Absender (verwenden Sie self dafür).

  • misc-by vermeidet die Einbeziehung von Personen, die in Acked-by, Reviewed-by, Tested-by und anderen "-by"-Zeilen im Patch-Body genannt werden, außer Signed-off-by (verwenden Sie sob dafür).

  • cccmd vermeidet die Ausführung von --cc-cmd.

  • body ist äquivalent zu sob + bodycc + misc-by.

  • all unterdrückt alle automatischen CC-Werte.

Standard ist der Wert des Konfigurationswerts sendemail.suppressCc; wenn dieser nicht angegeben ist, wird standardmäßig self verwendet, wenn --suppress-from angegeben ist, sowie body, wenn --no-signed-off-cc angegeben ist.

--suppress-from
--no-suppress-from

Wenn dies gesetzt ist, wird die From:-Adresse nicht zur Cc:-Liste hinzugefügt. Standard ist der Wert des Konfigurationswerts sendemail.suppressFrom; wenn dieser nicht angegeben ist, wird standardmäßig --no-suppress-from verwendet.

--thread
--no-thread

Wenn dies gesetzt ist, werden die Header In-Reply-To und References zu jeder gesendeten E-Mail hinzugefügt. Ob jede E-Mail auf die vorherige E-Mail (tiefe Threading laut git format-patch) oder auf die erste E-Mail (flache Threading) verweist, wird durch --[no-]chain-reply-to gesteuert.

Wenn mit --no-thread deaktiviert, werden diese Header nicht hinzugefügt (es sei denn, sie werden mit --in-reply-to angegeben). Standard ist der Wert des Konfigurationswerts sendemail.thread; wenn dieser nicht angegeben ist, wird standardmäßig --thread verwendet.

Es liegt in der Verantwortung des Benutzers sicherzustellen, dass kein In-Reply-To-Header bereits existiert, wenn git send-email aufgefordert wird, ihn hinzuzufügen (beachten Sie insbesondere, dass git format-patch so konfiguriert werden kann, dass es das Threading selbst durchführt). Wenn dies nicht geschieht, wird das Ergebnis im MUA des Empfängers möglicherweise nicht wie erwartet sein.

--mailmap
--no-mailmap

Verwendet die mailmap-Datei (siehe gitmailmap[5]), um alle Adressen auf ihren kanonischen echten Namen und ihre E-Mail-Adresse abzubilden. Zusätzliche mailmap-Daten, die spezifisch für git send-email sind, können über die Konfigurationswerte sendemail.mailmap.file oder sendemail.mailmap.blob bereitgestellt werden. Standard ist sendemail.mailmap.

Verwaltung

--confirm=<modus>

Bestätigung kurz vor dem Senden

  • always bestätigt immer vor dem Senden.

  • never bestätigt nie vor dem Senden.

  • cc bestätigt vor dem Senden, wenn send-email automatisch Adressen aus dem Patch zur Cc-Liste hinzugefügt hat.

  • compose bestätigt vor dem Senden der ersten Nachricht, wenn --compose verwendet wird.

  • auto ist äquivalent zu cc + compose.

Standard ist der Wert des Konfigurationswerts sendemail.confirm; wenn dieser nicht angegeben ist, wird standardmäßig auto verwendet, es sei denn, eine der Unterdrückungsoptionen wurde angegeben, in welchem Fall standardmäßig compose verwendet wird.

--dry-run

Alles tun, außer die E-Mails tatsächlich zu senden.

--format-patch
--no-format-patch

Wenn ein Argument entweder als Referenz oder als Dateiname verstanden werden kann, wird es als format-patch-Argument (--format-patch) oder als Dateiname (--no-format-patch) verstanden. Standardmäßig schlägt git send-email fehl, wenn ein solcher Konflikt auftritt.

--quiet

Macht git send-email weniger gesprächig. Eine Zeile pro E-Mail sollte alles sein, was ausgegeben wird.

--validate
--no-validate

Führt Plausibilitätsprüfungen an Patches durch. Aktuell bedeutet Validierung Folgendes:

  • Ruft den sendemail-validate Hook auf, falls vorhanden (siehe githooks[5]).

  • Warnt vor Patches, die Zeilen mit mehr als 998 Zeichen enthalten, es sei denn, es wird eine geeignete Transferkodierung (auto, base64 oder quoted-printable) verwendet; dies liegt an SMTP-Beschränkungen, wie in https://www.ietf.org/rfc/rfc5322.txt beschrieben.

Standard ist der Wert von sendemail.validate; wenn dieser nicht gesetzt ist, wird standardmäßig --validate verwendet.

--force

Sendet E-Mails auch dann, wenn Sicherheitsprüfungen dies verhindern würden.

Information

--dump-aliases

Anstatt des normalen Betriebs werden die Kurznamen der Aliase aus den konfigurierten Alias-Dateien ausgegeben, eine pro Zeile in alphabetischer Reihenfolge. Beachten Sie, dass hierbei nur der Aliasname und nicht seine erweiterten E-Mail-Adressen enthalten sind. Weitere Informationen zu Aliassen finden Sie unter sendemail.aliasesFile.

--translate-aliases

Anstatt des normalen Betriebs wird von der Standardeingabe gelesen und jede Zeile als E-Mail-Alias interpretiert. Dieser wird gemäß den konfigurierten Alias-Dateien übersetzt. Die übersetzten Namen und E-Mail-Adressen werden jeweils eine pro Zeile auf die Standardausgabe ausgegeben. Weitere Informationen zu Aliassen finden Sie unter sendemail.aliasFile.

KONFIGURATION

Alles unterhalb dieser Zeile in diesem Abschnitt wird selektiv aus der git-config[1]-Dokumentation übernommen. Der Inhalt ist derselbe wie dort zu finden.

sendemail.identity

Eine Konfigurationsidentität. Wenn angegeben, bewirkt dies, dass Werte im Abschnitt sendemail.<identität> Vorrang vor Werten im Abschnitt sendemail haben. Die Standardidentität ist der Wert von sendemail.identity.

sendemail.smtpEncryption

Siehe git-send-email[1] für die Beschreibung. Beachten Sie, dass diese Einstellung nicht dem Mechanismus identity unterliegt.

sendemail.smtpSSLCertPath

Pfad zu den CA-Zertifikaten (entweder ein Verzeichnis oder eine einzelne Datei). Setzen Sie ihn auf eine leere Zeichenkette, um die Zertifikatsüberprüfung zu deaktivieren.

sendemail.<identity>.*

Identitätsspezifische Versionen der unten aufgeführten Parameter sendemail.*, die Vorrang vor diesen haben, wenn diese Identität ausgewählt wird, entweder über die Befehlszeile oder sendemail.identity.

sendemail.multiEdit

Wenn true (Standard), wird eine einzige Editorinstanz gestartet, um Dateien zu bearbeiten, die Sie bearbeiten müssen (Patches, wenn --annotate verwendet wird, und die Zusammenfassung, wenn --compose verwendet wird). Wenn false, werden die Dateien nacheinander bearbeitet, wobei jedes Mal ein neuer Editor gestartet wird.

sendemail.confirm

Legt den Standardwert für die Bestätigung vor dem Senden fest. Muss einer der Werte always, never, cc, compose oder auto sein. Die Bedeutung dieser Werte finden Sie unter --confirm in der Dokumentation von git-send-email[1].

sendemail.mailmap

Wenn true, wird git-send-email[1] annehmen, dass --mailmap verwendet wird, andernfalls wird --no-mailmap angenommen. Standardmäßig ist false.

sendemail.mailmap.file

Der Speicherort einer spezifischen, ergänzenden Mailmap-Datei für git-send-email[1]. Die Standard-Mailmap und mailmap.file werden zuerst geladen. Einträge in dieser Datei haben daher Vorrang vor Einträgen an den Standard-Mailmap-Speicherorten. Siehe gitmailmap[5].

sendemail.mailmap.blob

Ähnlich wie sendemail.mailmap.file, aber der Wert wird als Referenz auf ein Blob im Repository betrachtet. Einträge in sendemail.mailmap.file haben Vorrang vor Einträgen hier. Siehe gitmailmap[5].

sendemail.aliasesFile

Um das Tippen langer E-Mail-Adressen zu vermeiden, weisen Sie hier auf eine oder mehrere Alias-Dateien hin. Sie müssen auch sendemail.aliasFileType angeben.

sendemail.aliasFileType

Format der in sendemail.aliasesFile angegebenen Datei(en). Muss einer der Werte mutt, mailrc, pine, elm, gnus oder sendmail sein.

Wie eine Alias-Datei in jedem Format aussieht, erfahren Sie in der Dokumentation des E-Mail-Programms mit demselben Namen. Die Unterschiede und Einschränkungen gegenüber den Standardformaten werden unten beschrieben.

sendmail
  • Anführungszeichen-Aliase und Anführungszeichen-Adressen werden nicht unterstützt: Zeilen, die ein "-Symbol enthalten, werden ignoriert.

  • Umleitung in eine Datei (/path/name) oder Pipe (|command) wird nicht unterstützt.

  • Dateieinbindung (:include: /path/name) wird nicht unterstützt.

  • Warnungen werden auf der Standardfehlerausgabe für explizit nicht unterstützte Konstrukte und alle anderen Zeilen ausgegeben, die vom Parser nicht erkannt werden.

sendemail.annotate
sendemail.bcc
sendemail.cc
sendemail.ccCmd
sendemail.chainReplyTo
sendemail.envelopeSender
sendemail.from
sendemail.headerCmd
sendemail.signedOffByCc
sendemail.smtpPass
sendemail.suppressCc
sendemail.suppressFrom
sendemail.to
sendemail.toCmd
sendemail.smtpDomain
sendemail.smtpServer
sendemail.smtpServerPort
sendemail.smtpServerOption
sendemail.smtpUser
sendemail.imapSentFolder
sendemail.useImapOnly
sendemail.thread
sendemail.transferEncoding
sendemail.validate
sendemail.xmailer

Diese Konfigurationsvariablen bieten alle einen Standardwert für die Befehlszeilenoptionen von git-send-email[1]. Weitere Einzelheiten finden Sie in dessen Dokumentation.

sendemail.outlookidfix

Wenn true, wird git-send-email[1] annehmen, dass --outlook-id-fix verwendet wird, und wenn false, wird angenommen, dass --no-outlook-id-fix verwendet wird. Wenn nicht angegeben, verhält es sich so, als ob --outlook-id-fix nicht angegeben wurde.

sendemail.signedOffCc (veraltet)

Veralteter Alias für sendemail.signedOffByCc.

sendemail.smtpBatchSize

Anzahl der pro Verbindung zu sendenden Nachrichten, danach wird eine erneute Anmeldung erfolgen. Wenn der Wert 0 oder undefiniert ist, werden alle Nachrichten in einer Verbindung gesendet. Siehe auch die Option --batch-size von git-send-email[1].

sendemail.smtpReloginDelay

Sekunden, die vor der Wiederverbindung mit dem SMTP-Server gewartet werden soll. Siehe auch die Option --relogin-delay von git-send-email[1].

sendemail.forbidSendmailVariables

Um häufige Fehlkonfigurationen zu vermeiden, bricht git-send-email[1] mit einer Warnung ab, wenn Konfigurationsoptionen für sendmail vorhanden sind. Setzen Sie diese Variable, um die Prüfung zu umgehen.

BEISPIELE FÜR SMTP-SERVER

Gmail als SMTP-Server verwenden

Um git send-email zum Senden Ihrer Patches über den Gmail SMTP-Server zu verwenden, bearbeiten Sie ~/.gitconfig, um Ihre Kontoeinstellungen anzugeben.

[sendemail]
	smtpEncryption = ssl
	smtpServer = smtp.gmail.com
	smtpUser = yourname@gmail.com
	smtpServerPort = 465

Gmail erlaubt nicht die Verwendung Ihres normalen Passworts für git send-email. Wenn Sie die Zwei-Faktor-Authentifizierung für Ihr Gmail-Konto eingerichtet haben, können Sie ein App-spezifisches Passwort für die Verwendung mit git send-email generieren. Besuchen Sie https://security.google.com/settings/security/apppasswords, um es zu erstellen.

Alternativ dazu können Sie anstelle eines App-spezifischen Passworts OAuth2.0-Authentifizierung mit Gmail verwenden. OAuth2.0 ist sicherer als App-spezifische Passwörter und funktioniert unabhängig davon, ob Sie die Zwei-Faktor-Authentifizierung eingerichtet haben oder nicht. OAUTHBEARER und XOAUTH2 sind gängige Mechanismen für diese Art von Authentifizierung. Gmail unterstützt beide. Wenn Sie beispielsweise OAUTHBEARER verwenden möchten, bearbeiten Sie Ihre Datei ~/.gitconfig und fügen Sie smtpAuth = OAUTHBEARER zu Ihren Kontoeinstellungen hinzu.

[sendemail]
	smtpEncryption = ssl
	smtpServer = smtp.gmail.com
	smtpUser = yourname@gmail.com
	smtpServerPort = 465
	smtpAuth = OAUTHBEARER

Eine weitere Alternative ist die Verwendung eines von Google entwickelten Tools namens sendgmail zum Senden von E-Mails mit git send-email.

Microsoft Outlook als SMTP-Server verwenden

Im Gegensatz zu Gmail unterstützt Microsoft Outlook keine App-spezifischen Passwörter mehr. Daher muss die OAuth2.0-Authentifizierung für Outlook verwendet werden. Außerdem unterstützt es nur den XOAUTH2-Authentifizierungsmechanismus.

Bearbeiten Sie ~/.gitconfig, um Ihre Kontoeinstellungen für Outlook anzugeben und dessen SMTP-Server mit git send-email zu verwenden.

[sendemail]
	smtpEncryption = tls
	smtpServer = smtp.office365.com
	smtpUser = yourname@outlook.com
	smtpServerPort = 587
	smtpAuth = XOAUTH2

PATCHES SENDEN

Sobald Ihre Commits zum Senden an die Mailingliste bereit sind, führen Sie die folgenden Befehle aus.

$ git format-patch --cover-letter -M origin/master -o outgoing/
$ edit outgoing/0000-*
$ git send-email outgoing/*

Wenn Sie ihn zum ersten Mal ausführen, werden Sie nach Ihren Anmeldeinformationen gefragt. Geben Sie das App-spezifische Passwort oder Ihr reguläres Passwort ein, je nachdem.

Wenn Sie einen Anmeldeinformations-Helfer konfiguriert haben (siehe git-credential[1]), wird das Passwort im Anmeldeinformationsspeicher gespeichert, sodass Sie es beim nächsten Mal nicht eingeben müssen.

Wenn Sie die OAuth2.0-Authentifizierung verwenden, müssen Sie anstelle eines Passworts einen Zugriffstoken eingeben, wenn Sie dazu aufgefordert werden. Verschiedene OAuth2.0-Token-Generatoren sind online verfügbar. Von der Community gepflegte Anmeldeinformations-Helfer sind ebenfalls verfügbar.

  • git-credential-gmail (plattformübergreifender, dedizierter Helfer zur Authentifizierung von Gmail-Konten)

  • git-credential-outlook (plattformübergreifender, dedizierter Helfer zur Authentifizierung von Microsoft Outlook-Konten)

  • git-credential-yahoo (plattformübergreifender, dedizierter Helfer zur Authentifizierung von Yahoo-Konten)

  • git-credential-aol (plattformübergreifender, dedizierter Helfer zur Authentifizierung von AOL-Konten)

Siehe auch gitcredentials[7] für weitere OAuth-basierte Authentifizierungshelfer.

Proton Mail stellt keinen SMTP-Server zum Senden von E-Mails zur Verfügung. Wenn Sie ein zahlender Kunde von Proton Mail sind, können Sie Proton Mail Bridge, das offiziell von Proton Mail bereitgestellt wird, verwenden, um einen lokalen SMTP-Server zum Senden von E-Mails zu erstellen. Für kostenlose und zahlende Benutzer können von der Community gepflegte Projekte wie git-protonmail verwendet werden.

Hinweis: Die folgenden Kern-Perl-Module, die mit Ihrer Perl-Distribution installiert sein können, werden benötigt.

Diese zusätzlichen Perl-Module werden ebenfalls benötigt.

Nutzung der sendmailCmd-Option von git send-email

Neben dem Senden von E-Mails über einen SMTP-Server kann git send-email auch E-Mails über jede Anwendung senden, die sendmail-ähnliche Befehle unterstützt. Sie können die Dokumentation zu --sendmail-cmd=<command> oben für weitere Informationen lesen. Diese Funktion kann sehr nützlich sein, wenn Sie eine andere Anwendung als SMTP-Client für git send-email verwenden möchten oder wenn Ihr E-Mail-Anbieter proprietäre APIs anstelle von SMTP zum Senden von E-Mails verwendet.

Als Beispiel sehen wir uns an, wie msmtp, ein beliebter SMTP-Client, der in vielen Linux-Distributionen verfügbar ist, konfiguriert wird. Bearbeiten Sie ~/.gitconfig, um git-send-email anzuweisen, ihn zum Senden von E-Mails zu verwenden.

[sendemail]
	sendmailCmd = /usr/bin/msmtp # Change this to the path where msmtp is installed

Links zu einigen solchen von der Community gepflegten Helfern sind:

  • msmtp (beliebter SMTP-Client mit vielen Funktionen, verfügbar für Linux und macOS)

  • git-protonmail (plattformübergreifender Client, der E-Mails über die ProtonMail API senden kann)

  • git-msgraph (plattformübergreifender Client, der E-Mails über die Microsoft Graph API senden kann)

SIEHE AUCH

GIT

Teil der git[1] Suite